| Time |
Nick |
Message |
| 00:51 |
|
sfan5 joined #minetest |
| 01:00 |
|
smk joined #minetest |
| 01:05 |
|
ShadowBot joined #minetest |
| 01:09 |
|
gxt joined #minetest |
| 01:17 |
|
olliy joined #minetest |
| 01:42 |
|
Fusl joined #minetest |
| 01:44 |
|
illwieckz joined #minetest |
| 01:59 |
|
Lesha_Vel joined #minetest |
| 02:17 |
|
sparky4 joined #minetest |
| 02:19 |
|
illwieckz joined #minetest |
| 02:55 |
|
Trifton joined #minetest |
| 02:57 |
|
Trifton joined #minetest |
| 03:01 |
|
Trifton joined #minetest |
| 03:16 |
|
fluxionary_ joined #minetest |
| 03:37 |
lissobone |
hi im back from slumber |
| 03:38 |
|
nm0i joined #minetest |
| 03:44 |
lissobone |
My fresh brain has realized why it needs two loops. |
| 03:50 |
|
nm0i joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:00 |
|
sid0 joined #minetest |
| 04:18 |
hare_hare_yukai |
hi cursed kid |
| 04:18 |
hare_hare_yukai |
rangedweapons has some insane source code btw |
| 04:19 |
hare_hare_yukai |
i remember i was trying to do something with guns, i was looking at ctf and rangedweapons |
| 04:20 |
hare_hare_yukai |
rangedweapons puts everything in zip archives on a git repo |
| 04:20 |
hare_hare_yukai |
indentation was... questionable |
| 04:21 |
lissobone |
yeah |
| 04:24 |
lissobone |
I don't like how map_id is generated. |
| 04:24 |
lissobone |
Changing it won't affect anything, it's for new maps only. |
| 04:25 |
|
illwieckz_ joined #minetest |
| 04:26 |
hare_hare_yukai |
did you eat kimchi today my fellow asian associate? |
| 04:26 |
lissobone |
i ate kimpap yesterday |
| 04:27 |
hare_hare_yukai |
did you eat that autism out of your brain too? i hope so |
| 04:27 |
lissobone |
i cycled for 2 hours, lost and stranded to the north of my city, and decided to buy one (it was with kimchi and tuna) |
| 04:27 |
muurkha |
I hope not, what would computers be like without autism? |
| 04:27 |
hare_hare_yukai |
i havent cycled in YEARS |
| 04:27 |
lissobone |
That's the very reason my ass muscles ache. |
| 04:28 |
hare_hare_yukai |
computers would be completely proprietary and nonfree i can assure you |
| 04:28 |
muurkha |
mmm, ass |
| 04:28 |
hare_hare_yukai |
thats how strong his autism is |
| 04:28 |
lissobone |
i am very autistic |
| 04:28 |
muurkha |
I don't think we'd have computers at all without autism |
| 04:28 |
hare_hare_yukai |
that may very well be true |
| 04:34 |
muurkha |
I just found the ghost blocks mod today because I was thinking about implementing something similar |
| 04:34 |
muurkha |
I haven't tried it yet |
| 04:34 |
hare_hare_yukai |
what do ghost blocks do? |
| 04:38 |
muurkha |
they look like regular blocks but you can walk through them |
| 04:38 |
lissobone |
I once trolled the enemy team in CTF like that. |
| 04:39 |
lissobone |
I wormed through a wall in their base and sealed my way with unwalkable cobblestone. |
| 04:39 |
lissobone |
They never noticed it. |
| 04:39 |
hare_hare_yukai |
what literally register_node and walkable = false ? |
| 04:48 |
|
lemonzest joined #minetest |
| 04:49 |
lissobone |
local minp = vector.multiply(vector.floor(vector.divide(pos, size)), size) |
| 04:49 |
lissobone |
I am in awe. |
| 04:50 |
|
lemonzest joined #minetest |
| 04:52 |
|
calcul0n joined #minetest |
| 04:55 |
lissobone |
This is clever. |
| 04:55 |
hare_hare_yukai |
SEEEEEEEEEEEEEEEEX |
| 05:01 |
muurkha |
that's just int(x/y) * y, isn't it? |
| 05:01 |
muurkha |
that's how I used to do x % y in BASIC when I didn't know about the modulo operator |
| 05:02 |
muurkha |
I mean, x - int(x/y) * y |
| 05:02 |
muurkha |
this is just "round down to nearest multiple of size", right? |
| 05:03 |
hare_hare_yukai |
pos is { x=int, y=int, z=int } |
| 05:04 |
hare_hare_yukai |
vector. functions require tables like that i think |
| 05:04 |
lissobone |
Yes, it rounds down to nearest multiple of size. |
| 05:04 |
lissobone |
And it's clever. |
| 05:05 |
hare_hare_yukai |
oh actually its just (0, 0, 0) |
| 05:05 |
hare_hare_yukai |
(x, y, z) |
| 05:05 |
muurkha |
you'll love this thing I wrote then: https://www.shadertoy.com/view/XtcBWH |
| 05:07 |
hare_hare_yukai |
hah my browser doesnt even support whats needed to run that |
| 05:07 |
muurkha |
sorry :( |
| 05:07 |
muurkha |
try a cellphone, they all seem to have great OpenGL ES support |
| 05:08 |
muurkha |
can you at least see the source code? |
| 05:08 |
hare_hare_yukai |
firefox works actually |
| 05:08 |
hare_hare_yukai |
wow, trippy |
| 05:08 |
hare_hare_yukai |
i like it |
| 05:08 |
muurkha |
:) |
| 05:09 |
muurkha |
we should have a 1024-byte shader contest |
| 05:10 |
muurkha |
this could be one entry |
| 05:10 |
hare_hare_yukai |
i think i know near squat about graphics programming |
| 05:10 |
|
doseijin joined #minetest |
| 05:11 |
muurkha |
I'm no expert myself, but I've written a few basic 3-D engines |
| 05:12 |
[MTMatrix] |
<Blockhead256> shader contest? sure, it's cool, but is it a Minetest shader? |
| 05:12 |
muurkha |
Blockhead256: we can use GLSL shaders in Minetest, right? |
| 05:14 |
[MTMatrix] |
<Blockhead256> I mean yeah, there's references to GLSL in the source code for the dynamic shadows and so on. I'm not sure we have a way to add a custom shader to say, a node or entity though. |
| 05:16 |
muurkha |
should we? |
| 05:16 |
hare_hare_yukai |
i sense this involves having to coooompile |
| 05:17 |
[MTMatrix] |
<Blockhead256> Maybe we should, could be cool. Maybe it would create portability issues with GL vs GLES, or maybe security vulnerabilities |
| 05:17 |
muurkha |
hare_hare_yukai: GL implementations are pretty good about compiling shaders at runtime |
| 05:17 |
[MTMatrix] |
<Blockhead256> If my experience with Steam tells me anything, most game engines compile the shaders on the client, it wouldn't require building from source or anything |
| 05:18 |
[MTMatrix] |
<Blockhead256> the only question is whether loading glsl fragments from a mod should maybe need extra permissions. I guess it's not much riskier than loading a static texture or model though, right? (since those can also be vectors for security vulnerabilities) |
| 05:19 |
[MTMatrix] |
<Blockhead256> having actual mirror nodes in Minetest would be cool. Even cooler would be one-way mirrors |
| 05:21 |
[MTMatrix] |
<Blockhead256> there's a trick you can do though, as long as the players can't see around too much. Put the toilet facilities underground or some place. Put a pane of glass in above the sink, and build a mirror image of the room on the other side of the glass so it looks like the reflection of the room. Works better if your players are vampires |
| 05:22 |
muurkha |
hahaha |
| 05:23 |
muurkha |
I'm not sure how secure GLSL implementations *really* are. they are sort of *intended* to only give the shader access to things that are explicitly granted to it |
| 05:23 |
muurkha |
but that kind of thing breaks pretty often |
| 05:47 |
lissobone |
Security is the last thing I think of. |
| 05:48 |
[MTMatrix] |
<Blockhead256> lissobone: Maybe something else like accessibility - bright flashing lights? Performance? Portability? |
| 06:07 |
|
v-rob joined #minetest |
| 06:13 |
hare_hare_yukai |
lissobone that's right, disable all those spectre mitigations |
| 06:19 |
lissobone |
erle: I have added protection. Testing. |
| 06:25 |
|
panwolfram joined #minetest |
| 06:32 |
lissobone |
Cool. I can place the map as a different player (not in the protected area), but not remove it. |
| 06:32 |
lissobone |
Gotta, like, restrict placing maps, too. |
| 06:39 |
lissobone |
Done, protection works. |
| 06:52 |
|
mrkubax10 joined #minetest |
| 06:53 |
|
s20 joined #minetest |
| 07:28 |
erle |
lissobone neat |
| 07:29 |
lissobone |
Ok, so, how do I push now? |
| 07:29 |
lissobone |
Emacs can do that, but I seem to be doing something wrong: fatal: could not read Username for 'https://git.minetest.land': No such device or address |
| 07:29 |
erle |
do you have an account on git.minetest.land? |
| 07:29 |
lissobone |
Well, no, and that appears to be the error. |
| 07:30 |
erle |
i think you'd have to make an account, then fork the repo, then add an SSH clone URL as an origin, then push |
| 07:30 |
erle |
that okay for you? |
| 07:31 |
lissobone |
Looks okay. |
| 07:31 |
erle |
honestly i did not think of protection at all |
| 07:31 |
lissobone |
Me neither, I just saw it in a TODO. |
| 07:31 |
lissobone |
But without protection one can place a map anywhere. Some may dislike this. |
| 07:32 |
[MTMatrix] |
<Blockhead256> most git forges use https:// URIs for read-only clones (or HTTP basic auth, if the still support that, which e.g. GitHub doesn't), and git domain.name:user/repository.git URIs for read-write over SSH |
| 07:33 |
[MTMatrix] |
<Blockhead256> erle already described the workflow for contributing on git forges |
| 07:34 |
erle |
lissobone and worse, without protection people may steal a map from anywhere |
| 07:36 |
lissobone |
"Steal"? I prefer "share". |
| 07:36 |
erle |
i don't think that xmaps has a copying facility, or did i add one? |
| 07:36 |
erle |
maybe i should |
| 07:36 |
erle |
like xmap + map = 2 maps |
| 07:36 |
erle |
or, better |
| 07:36 |
erle |
clicking a placed map with your own map copies it? |
| 07:40 |
erle |
then you could copy placed maps |
| 07:40 |
lissobone |
Why not add both? |
| 07:40 |
erle |
because it's more code obv |
| 07:41 |
erle |
and why have two things to do the same stuff when one of them is more useful? |
| 07:41 |
erle |
i think crafting-wise what would be interesting would be zoomed-out maps |
| 07:42 |
erle |
lissobone when you make a PR please keep concerns separate, it should ideally only affect one feature/thing |
| 07:42 |
erle |
thanks! |
| 07:46 |
erle |
lissobone thank you for contributing! |
| 07:47 |
lissobone |
I have made an account, and now I think I need to specify directly where to push. |
| 07:49 |
erle |
1. fork the repo in the web interface |
| 07:49 |
erle |
2. look for the ssh clone url |
| 07:49 |
erle |
3. git remote rm origin |
| 07:49 |
erle |
4. git remote add origin $CLONE_URL |
| 07:49 |
erle |
5. git push |
| 07:50 |
erle |
it must be the ssh clone url of your own repo obv |
| 07:55 |
erle |
> having actual mirror nodes in Minetest would be cool. Even cooler would be one-way mirrors |
| 07:55 |
erle |
Blockhead256 you do not need shaders for that though |
| 07:56 |
erle |
> I guess it's not much riskier than loading a static texture or model though, right? (since those can also be vectors for security vulnerabilities) |
| 07:56 |
erle |
loading code is always riskier than loading static data |
| 07:56 |
muurkha |
that's not true |
| 07:56 |
erle |
okay, i was simplifying it too much |
| 07:56 |
muurkha |
lots of historical CVEs in PNG and JPEG decoders |
| 07:57 |
[MTMatrix] |
<Blockhead256> at some point the code-data distinction blurs anyway |
| 07:57 |
muurkha |
see, that's what Meredith keeps saying we should stop doing ;) |
| 07:57 |
[MTMatrix] |
<Blockhead256> `git remote set-url origin $CLONE_URL`, no need to remove and re-add |
| 07:58 |
erle |
loading code/data in a format which can not be fully verified by a deterministic pushdown-automaton (except for calc-regular languages) means that no amount of testing is leading to getting it right |
| 07:58 |
erle |
muurkha satisfied? |
| 07:58 |
erle |
also i am pretty sure that PNG is context-sensitive because it has checksums |
| 07:59 |
muurkha |
Blockhead256: I just vi .git/config, didn't know about remote set-url |
| 07:59 |
lissobone |
Well, I have forked it. Through the web interface. |
| 07:59 |
lissobone |
And I have the ssh url. |
| 08:00 |
muurkha |
erle: I don't know, I suppose that's true but I'm not sure it really cuts to the core of the matter |
| 08:00 |
[MTMatrix] |
<Blockhead256> you can learn a lot of shortcuts with `git help`. Or you can learn long-cuts like fetching and merging separately instead of pulling.. |
| 08:00 |
erle |
i think non-RLE TGA can *almost* be verified by a regular expression. it is calc-regular because you need to figure out how many bytes the payload should contain. so in practice, it would be a regular expression plus one length check afterwards. |
| 08:01 |
muurkha |
erle: a lot of CVEs in libjpeg weren't just "it fails to halt" |
| 08:01 |
erle |
the halting problem is merely the most obvious problem here |
| 08:01 |
lissobone |
So, I have the url: ssh://gitgit.minetest.land:29418/lissobone/xmaps-forked2.git |
| 08:01 |
muurkha |
it's easy to write parsers for calc-regular languages that have buffer overflows in them |
| 08:01 |
erle |
did you read “the seven turrets of babel”? i would assume so, but if not, section III (i think) contains lots of examples of what can go wrong that is not the halitng problem. |
| 08:02 |
lissobone |
Next step is to git remote add origin? |
| 08:02 |
muurkha |
I don't think I have |
| 08:02 |
erle |
muurkha one second |
| 08:02 |
erle |
it's one of my favourite papers |
| 08:03 |
erle |
The Seven Turrets of Babel: A Taxonomy of LangSec Errors and How to Expunge Them, Falcon Darkstar Momot, Sergey Bratus, Sven M. Hallberg, Meredith L. Patterson http://langsec.org/papers/langsec-cwes-secdev2016.pdf |
| 08:04 |
erle |
when i work with someone new on programming stuff, i often tell them to read first “Security Applications of Formal Language Theory”, then “The Seven Turrets of Babel” |
| 08:04 |
erle |
from my entirely unscientific observations it has the same effect as pestering a junior dev about mistakes for about 3 months |
| 08:04 |
muurkha |
heh |
| 08:05 |
erle |
which means it has the best effort-to-result ratio by far of all texts about programming i know |
| 08:05 |
muurkha |
have you looked at Hammer? |
| 08:05 |
erle |
no, but i know it exists. i don't write many parsers. |
| 08:06 |
erle |
i mean maybe the effort-to-result ratio of john regehrs musings about undefined behaviour is good too, but it is entirely limited to C and C++ |
| 08:06 |
erle |
whereas the babel thing is universal and gives people a taxonomy of mistakes they can make plus easily understandable examples |
| 08:06 |
erle |
afterwards people often say “yes i have seen that situation, in my own code!” |
| 08:07 |
erle |
muurkha do you think i should look at hammer? |
| 08:10 |
erle |
Blockhead256 i suggest to read both “Security Applications of Formal Language Theory” and “The Seven Turrets of Babel” so we can shortcut that argument about shaders |
| 08:12 |
|
Alnotz joined #minetest |
| 08:12 |
[MTMatrix] |
<Blockhead256> yeah I'm not about to argue over that, I can recall a bit about chomsky hierarchy so obviously code which is a language higher up the hierarchy is going to be harder to secure than data which is lower on the hierarchy |
| 08:13 |
erle |
yeah but at some point ”harder to secure” becomes “impossible to secure” |
| 08:14 |
erle |
or impossible to do other useful stuff with |
| 08:14 |
erle |
e.g. perl can not be parsed |
| 08:14 |
[MTMatrix] |
<Blockhead256> In the context of Minetest I think given how much uncertainty there is of ever getting server-sent CSM, the same uncertainty can just be levelled at shaders, so I don't see it happening |
| 08:14 |
erle |
IIRC every perl syntax highlighting is necessarily wrong unless it executes the entire perl program up to that point |
| 08:14 |
erle |
because you can redefine symbols at runtime or something weird like that, i don't remember the details |
| 08:15 |
erle |
no static code analysis for the perl clan! |
| 08:15 |
erle |
no parser generators for perl too i guess |
| 08:17 |
erle |
Blockhead256 i think server-sent CSM is a fantasy by people that have not looked too much at what CSMs are actually used for mostly. |
| 08:17 |
erle |
the “cheat client” dragonfire uses CSMs like browsers use extensions. i.e. the user decides to install them on the client and the server can not do anything, including detecting if a CSM is used. |
| 08:18 |
erle |
that latter capability would lead to ”you can not join this server without using a CSM” obviously |
| 08:18 |
erle |
the browser-extension or emacs-elisp model works very well in cheat clients. |
| 08:18 |
erle |
the only thing that is missing is menu and contentDB support for CSMs i think |
| 08:19 |
muurkha |
erle: I do think Hammer is pretty cool |
| 08:19 |
erle |
i think lizzy made a CSM database called cheatdb at some point |
| 08:19 |
erle |
https://github.com/dragonfireclient/cheatdb |
| 08:20 |
muurkha |
Perl cannot be parsed, but Amazon running your Perl on their EC2 server doesn't allow you to mail yourself free books |
| 08:20 |
muurkha |
so I don't think it's impossible to secure |
| 08:20 |
erle |
yet |
| 08:21 |
erle |
i'm pretty sure i have a GPU that is able to commit sudoku when someone sends it a bad shader |
| 08:21 |
erle |
i once won a CTF in the midst of summer in a very hot tent … and a 3D animation played. then my computer turned off. |
| 08:22 |
erle |
i feared i was hacked … but no, the website had overheated my computer through use of 3D effects! |
| 08:22 |
muurkha |
haha |
| 08:23 |
erle |
well “won” is wrong here. |
| 08:23 |
erle |
i “passed” |
| 08:23 |
erle |
i.e. all challenges done |
| 08:23 |
erle |
of the “kids” track :P |
| 08:23 |
[MTMatrix] |
<Blockhead256> that ellipsis got mangled by the Matrix bridge :( |
| 08:23 |
erle |
muurkha do you know something like hammer but for lua parsers? |
| 08:24 |
[MTMatrix] |
<Blockhead256> I think a shader competition for Minetest could be cool, but I think it would have to be on a modified engine where you can define custom shaders for a node |
| 08:24 |
erle |
muurkha i am not sure if JPEG can be validated in a regular way, but i do know that i can generate JPEG thumbnails by looking for specific bytes and just cutting of the file afterwards (if it contains multiple scans), i.e. with a shell script |
| 08:24 |
[MTMatrix] |
<Blockhead256> coolest node wins |
| 08:25 |
muurkha |
erle: you can totally use Hammer from LuaJIT |
| 08:25 |
erle |
hmmmmm |
| 08:25 |
erle |
wdym? |
| 08:26 |
erle |
like, parse stuff from lua? |
| 08:26 |
erle |
Blockhead256 i have no idea why people would care … after all, bump mapping and parallax occlusion effects were removed from the engine when it turns out they were buggy, only to never return. |
| 08:26 |
muurkha |
right, invoke the Hammer combinators via LuaJIT's FFI to build up your grammar |
| 08:26 |
erle |
well they were removed from minetest first |
| 08:26 |
muurkha |
erle: aw, that's too bad |
| 08:26 |
erle |
muurkha FFI means i can't put it on cdb and have it work right? |
| 08:26 |
muurkha |
erle: definitely not |
| 08:27 |
muurkha |
you might look at Pylon and the related Bridge tools, ggg |
| 08:27 |
erle |
i should stop asking questions with negations |
| 08:27 |
erle |
what does ”ggg” mean? |
| 08:27 |
[MTMatrix] |
<Blockhead256> I'm sure bump mapping will come back when it's ready, we've had all those other graphics effects like the dynamic shadows and bloom. When it does come back, I expect it will actually support real bump maps not just edge detection |
| 08:27 |
muurkha |
something grammar |
| 08:27 |
muurkha |
I forget what the supposed expansion is |
| 08:28 |
erle |
Blockhead256 dynamic shadows have been in irrlicht forever and i repeatedly mentioned that they can be used and that was ignored. |
| 08:28 |
erle |
granted, those are doom-3-style shadows |
| 08:28 |
erle |
but they have *crisp* edges |
| 08:28 |
erle |
not like the blurry mess that you get with an undersampled shadow map |
| 08:28 |
erle |
also i believe you get correct self-shadowing for free. no colored shadows though. |
| 08:29 |
erle |
it's a trade-off. crisp edges or colored shadows. i prefer crisp edges a lot. |
| 08:29 |
erle |
(also they are more performant i think) |
| 08:29 |
[MTMatrix] |
<Blockhead256> crisp edges I think has a worse aesthetic for leaves, which are a common visual feature |
| 08:30 |
erle |
(in that irrlicht shadow volumes work on a potato PC and minetests shadow maps stuff … not) |
| 08:31 |
erle |
well, yeah. some people prefer this, others prefer that. but what i wanted to say is that an easily accessible library feature was ignored for *years*. which leads me to the conclusion that no one really wanted shadows that much. |
| 08:33 |
[MTMatrix] |
<Blockhead256> there's a big disconnect between what the people want and what the devs do, otherwise we'd have the big changes like larger worlds by now. I take it the core devs just accepted what work was done rather than object. I'm not saying it's not a missed opportunity to have not used irrlicht's shadows. Do you have a screenshot of those? |
| 08:33 |
erle |
you literally only have to turn on the stencil buffer handling and call addShadowVolumeSceneNode() on a mesh |
| 08:34 |
erle |
oh, there is setShadowColor() too |
| 08:34 |
erle |
but i guess it's only a single color for each shadow |
| 08:34 |
erle |
oh no, it's globally for all shadows |
| 08:35 |
erle |
Blockhead256 i have a screenshot of those, even a comic, haha |
| 08:35 |
erle |
Blockhead256 https://mister-muffin.de/p/Aaqj.png ;) |
| 08:35 |
lissobone |
yayyyy i pushed it |
| 08:36 |
erle |
Blockhead256 alternatively, look here. the screenshot is a bit lame, but it shows dynamic shadows and multiple lights i think https://irrlicht.sourceforge.io/docu/example008.html |
| 08:37 |
erle |
let's see if i have that thing still compile |
| 08:40 |
erle |
Blockhead256 i made a screenshot, one moment please |
| 08:42 |
erle |
Blockhead256 here: smooth dynamic shadows with OpenGL 1.4 on Intel 945GM https://mister-muffin.de/p/UvqB.jpg |
| 08:42 |
erle |
note that the dwarf has *multiple* shadows |
| 08:42 |
erle |
i think these are the doom3 shadows |
| 08:42 |
erle |
on the same hardware, minetest shadow maps make the hardware grind to a halt |
| 08:43 |
erle |
oh also the water is waving despite me having a potato GPU here but i guess that's beside the point |
| 08:44 |
[MTMatrix] |
<Blockhead256> it's an interesting thought, but I just don't think those shadows have the same appeal as the shadow maps. They're quite aliased. Should we have it in there for the lower spec hardware? Maybe, but I think I know what implementation is going to win a popularity contest (and it's not the one that's going to win a benchmark) |
| 08:45 |
erle |
wdym ”quite aliased”? |
| 08:46 |
erle |
they are as aliased as the entire scene is |
| 08:46 |
erle |
like look at the boundaries between the walls |
| 08:46 |
erle |
this is a tech demo |
| 08:46 |
[MTMatrix] |
<Blockhead256> opposite of "anti-aliased". The helmet's shadow is quite jagged |
| 08:46 |
[MTMatrix] |
<Blockhead256> Minetest has kind of decided in some ways that it's not going to run on older hardware and operating systems forever, like how they have moved forward several C++ versions |
| 08:46 |
erle |
yes, you might have noticed that *every* hard edge in that scene is jagged |
| 08:46 |
[MTMatrix] |
<Blockhead256> ok true the whole scene has no AA. Irrlicht obviously has AA, it's in MInetest |
| 08:47 |
erle |
yeah |
| 08:47 |
erle |
it's a tech demo |
| 08:47 |
erle |
but my argument was not about shadow maps vs shadow volumes here, more like “as long as irrlicht was not gutted, every version of minetest (at least since 2013, probably earlier) could have had this with a 20 line patch or so and no one ever did it” |
| 08:48 |
erle |
you need to setup lights too so that the sun works i guess |
| 08:49 |
[MTMatrix] |
<Blockhead256> with dynamic shadows, all the torches are light sources too.. they don't seem to cast shadows though, just remove them.. |
| 08:49 |
erle |
at least to me “we need a new rendering infrastructure so that we can have better effects” is less believable when you are not using the existing effects |
| 08:49 |
erle |
oh, i think that would actually be easy with this thing |
| 08:49 |
erle |
irrlicht has a light manager, where you can, for example, cast shadows only for the 8 nearest lights or so |
| 08:50 |
erle |
because no one is going to care if a torch far away casts no shadow |
| 08:51 |
erle |
https://irrlicht.sourceforge.io/docu/example020.html |
| 08:54 |
erle |
Blockhead256 if you want a render-to-texture thing for mirrors or cameras, you can probably either start with the PRs from kilbith (the male model) or https://irrlicht.sourceforge.io/docu/example013.html |
| 08:54 |
erle |
portals! |
| 08:55 |
[MTMatrix] |
<Blockhead256> 8 sounds kinda few. Imagine an underground hall lined with lights and a render distance of 200. Does minetest use a single "scene node"? |
| 08:55 |
erle |
Blockhead256 read the linked text fully please |
| 08:55 |
erle |
8 is the minimum *guaranteed* by the hardware |
| 08:56 |
erle |
there is lots of trickery employed to support more |
| 08:56 |
erle |
Blockhead256 if you want to truly enjoy these examples, download irrlicht and compile them. it helps a lot to appreciate what is possible. |
| 08:56 |
erle |
well, it helped me |
| 08:57 |
erle |
and if you want to have shadows for dropped items, i guess you could use the addshadowvolume or how it is called. no one is going to care if the shadow for the dropped item is not colored. |
| 08:57 |
erle |
or you fake it and project a circle or cube from above lol (that's actually more work i guess) |
| 09:01 |
erle |
Blockhead256 these video are almost as old as minetest is https://onion.tube/watch?v=NgFxZX7saTQ https://onion.tube/watch?v=z9njr9jSkaY |
| 09:01 |
erle |
i like the bug here |
| 09:01 |
erle |
> Shadow volume calculated in different thread. With animated meshes there is a problem - when we actually see the shadow, we see the shadow for some previous frame |
| 09:01 |
erle |
(obviously that is a problem of the uploader) |
| 09:04 |
[MTMatrix] |
<Blockhead256> ah, and that first one uses a common trick where the shadow framerate is slower than the normal one.. which is fine, as long the shadows don't move too fast or the player doesn't look at them |
| 09:06 |
erle |
yeah but i think you don't really need to do that |
| 09:07 |
erle |
it's obviuosly good for static meshes though |
| 09:09 |
[MTMatrix] |
<Blockhead256> I agree it seems wasteful to not turn the stencil shadows on |
| 09:09 |
[MTMatrix] |
<Blockhead256> (though it's really not clear just what the reasonable range of hardware support for sources of light is - how much higher it goes than 8 and on what models) |
| 09:10 |
[MTMatrix] |
<Blockhead256> The entity shading that I take for granted now was probably sitting there since the dawn of time too |
| 09:14 |
[MTMatrix] |
<Blockhead256> *what model GPUs |
| 09:56 |
erle |
Blockhead256 read the light manager thing, the trick is to turn the lights on and off during rendering |
| 09:56 |
erle |
that way you can fake having more lights than the hardware supports |
| 09:57 |
erle |
for me (a very uninformed person never writing a game engine, haha) this is also an argument against directly doing the openGL thing. if you have an abstraction between openGL (or vulkan, or whatever) and your programmer, you can employ trickery |
| 10:26 |
erle |
i think i lied, i have only written 2d game engine stuff. doesn't take much away from my lack of experience with 3d. |
| 10:27 |
erle |
like, tile engine and roguelike stuff |
| 10:33 |
|
appguru joined #minetest |
| 11:01 |
erle |
lissobone take this donut.lua (put it in the source directory of tga_encoder and run it, see donut.tga for results) https://mister-muffin.de/p/RBQa |
| 11:07 |
hare_hare_yukai |
mfw holding space and w is faster when going up diagonally than with stair blocks |
| 11:10 |
[MTMatrix] |
<Blockhead256> in moreblocks there's a 2:1 slope (2 metres vertical per metre horizontal) that you can walk up and it's even faster |
| 11:57 |
|
erstazi_ joined #minetest |
| 12:05 |
erle |
muurkha any idea what the easiest way is to make this donut rendering solid? |
| 12:43 |
erle |
i rendered a donut using donut.lua here <https://mister-muffin.de/p/P_eT> donut.png here <https://mister-muffin.de/p/0Zit.png> |
| 12:43 |
erle |
(needs to be in the same directory as tga_encoder to work) |
| 12:44 |
MTDiscord |
<luatic> pro tip: call the donut a torus to sound smarter |
| 13:00 |
|
Sobinec joined #minetest |
| 13:08 |
erle |
luatic give me the cheat code for rendering a solid torus pls |
| 14:24 |
|
mrkubax10 joined #minetest |
| 14:49 |
MTDiscord |
<luatic> I think I've found memory unsafeties in Minetest |
| 14:51 |
|
definitelya joined #minetest |
| 14:52 |
MTDiscord |
<scout54> are we supposed to be surprised by this |
| 14:53 |
erle |
the donut code is now a tga_encoder demo of how to do 3d rendering :D https://git.minetest.land/erlehmann/tga_encoder/src/branch/master/donut.lua |
| 14:54 |
MTDiscord |
<luatic> erle: bad apple in minetest but it's a b3d |
| 14:54 |
MTDiscord |
<luatic> https://cdn.discordapp.com/attachments/749727888659447960/1153343259339391066/Bildschirmaufzeichnung_vom_18.09.2023_165211.webm |
| 14:55 |
MTDiscord |
<luatic> the dirt nodes in the air were NOT placed by me; the longer i let this run the more random dirt blocks i get in the world, i think something funky is happening with memory there |
| 14:55 |
MTDiscord |
<luatic> https://cdn.discordapp.com/attachments/749727888659447960/1153343453632151623/Bildschirmfoto_vom_2023-09-18_16-52-55.png |
| 14:55 |
erle |
as a b3d |
| 14:55 |
erle |
is this just having black and white pixels in b3d |
| 14:55 |
erle |
and having a cursed animation? |
| 14:56 |
erle |
like bringing them to front and back |
| 14:56 |
MTDiscord |
<luatic> it has black pixels, a white screen, and a cursed animation that moves pixels in front of / behind the white screen |
| 14:56 |
MTDiscord |
<luatic> the animation is of course interpolated, which causes the funny artifacts |
| 14:56 |
MTDiscord |
<luatic> i tried it with setting scale from 0 to 1 first, but that didn't quite go as expected |
| 14:56 |
erle |
well, as you may have noticed, the donut rendering function is called render_frame() |
| 14:57 |
erle |
you can surely make it dance |
| 14:57 |
erle |
you are a horribly funny person, with a focus on horribleness obviously |
| 14:57 |
erle |
my respects lol |
| 14:57 |
erle |
do you have a library to do this kind of shit? |
| 14:57 |
erle |
also compile minetest with ubsan and look if it gives you any pointers ig |
| 14:58 |
MTDiscord |
<luatic> erle: yeah, modlib is doing most of the heavy lifting here (png reading, b3d writing) |
| 14:59 |
erle |
b3d should probably be deprecated to prevent any future crimes lol |
| 14:59 |
erle |
have anything else that is funny about b3d? |
| 14:59 |
erle |
like funny hacks |
| 15:00 |
erle |
also did you try mm3d? |
| 15:00 |
MTDiscord |
<luatic> erle: don't think so, normally i'm not a horribly funny person |
| 15:00 |
erle |
important: run it with LANG=C, otherwise your locale affects the saves (stupid, isn't it?) |
| 15:00 |
|
sparky4_ joined #minetest |
| 15:00 |
MTDiscord |
<luatic> (to underline just how boring i usually am: last round of esolangs.gay code guessing i wrote a boring cli 2048 in rust) |
| 15:01 |
erle |
what |
| 15:01 |
MTDiscord |
<luatic> erle: i don't normally do modeling / making textures, didn't really try mm3d, but might get back to it if i resume work on some mods |
| 15:02 |
MTDiscord |
<luatic> erle: https://cg.esolangs.gay/42/ |
| 15:02 |
erle |
> girls just wanna have fun |
| 15:02 |
erle |
it's only gay if you also girl |
| 15:02 |
erle |
checkmate |
| 15:03 |
erle |
> Players write code to confuse each other, then try to guess which person wrote which bit of code. |
| 15:03 |
erle |
oh this is a fun concept |
| 15:04 |
erle |
> open to members of the Esolangs Discord Server |
| 15:04 |
erle |
nah, i'll pass |
| 15:05 |
erle |
> log in with discord |
| 15:05 |
erle |
hahahaha |
| 15:15 |
|
fluxionary_ joined #minetest |
| 15:17 |
erle |
luatic i want to point out that in my donut thing it works out naturally, because both in 3d space and in 2d space y goes UP hahahaha |
| 15:17 |
erle |
otherwise you'd have to mirror the picture |
| 15:17 |
|
vampirefrog joined #minetest |
| 15:23 |
MTDiscord |
<luatic> it does indeed appear to be upside down due to that |
| 15:24 |
|
fluxionary_ joined #minetest |
| 15:26 |
|
jaca122 joined #minetest |
| 15:38 |
|
v-rob joined #minetest |
| 15:38 |
|
s20 joined #minetest |
| 16:19 |
MinetestBot |
[git] rollerozxa -> minetest/minetest: Build MkDocs Lua API docs using GitHub CI, deploy to api.minetest.net… 5949172 https://github.com/minetest/minetest/commit/5949172735fa2cfdb3cf23c6512b748c876d8a48 (2023-09-18T16:17:18Z) |
| 16:19 |
lissobone |
why not texinfo |
| 16:22 |
muurkha |
erle: it looks like you're rendering the donut as a point cloud |
| 16:23 |
muurkha |
if you want a it to look solid, you have several different possible options |
| 16:24 |
jonadab |
Speaking of donuts, has anyone ever thought about a voxel world with torroidal topology (i.e., coordinates wrap around from max-negative to max-positive and vice versa in all dimensions)? |
| 16:25 |
muurkha |
the absolutely easiest is just to render a lot of points or, equivalently, in very low resolution |
| 16:26 |
jonadab |
I guess that would be hypertorroidal, with three coords. |
| 16:27 |
muurkha |
the next easiest is maybe to render each point as a square. if the points are spread evenly over the surface, or close enough (I think your torus is close enough) you can just use the farthest point spacing on the surface, divided by the distance, times √2 |
| 16:27 |
muurkha |
jonadab: that reminds me of the new Greg Egan story |
| 16:28 |
muurkha |
jonadab: https://www.gregegan.net/DIDICOSM/Complete/Didicosm.html |
| 16:30 |
muurkha |
erle: next easiest is to use a rendering method other than point clouds; the popular alternatives are Whitted-style ray tracing like POVRay, SDF-style raytracing like iquelezles, and polygon scan conversion |
| 16:47 |
muurkha |
*iquilezles |
| 16:51 |
|
appguru joined #minetest |
| 16:52 |
muurkha |
for a torus, the Whitted-style ray-tracing approach, where you find a closed-form solution for the ray-primitive intersection, usually involves invoking a general solver for quartic equations (I did not know this) |
| 16:53 |
muurkha |
the quartic equation in question is fairly simple, while a quartics solver is significantly less simple. but maybe you already have one on your shelf |
| 16:54 |
muurkha |
an alternative is to use the closed-form solution in https://arxiv.org/pdf/2301.03191.pdf |
| 16:56 |
muurkha |
by contrast, the SDF of a torus is pretty simple; in https://iquilezles.org/articles/distfunctions/ iq gives it in GLSL as length(vec2(length(p.xz)-t.x,p.y)) - t.y |
| 16:56 |
muurkha |
where t.x is the major radius of the torus and t.y is its minor diameter |
| 16:57 |
muurkha |
that's what I did in https://gitlab.com/kragen/bubbleos/blob/master/yeso/sdf.lua |
| 16:57 |
muurkha |
which is actually significantly less code than your pointcloud approach |
| 16:57 |
|
Sobinec joined #minetest |
| 16:58 |
muurkha |
that actually renders a CSG scene composed from three tori: a difference of a union of two tori, and a torus |
| 16:58 |
jonadab |
Solving quartics in the general case is a nightmare. |
| 17:00 |
muurkha |
it's not that bad, about four pages of code: https://github.com/mikestaub/Ray-Tracer/blob/master/raytracer/Utilities/Maths.cpp |
| 17:02 |
muurkha |
erle: in http://canonical.org/~kragen/sw/torus I rendered a rotating torus using triangle rasterization. in JS, not Lua, but maybe it's close enough |
| 17:06 |
erle |
muurkha the lots-of-points idea is sadly computationally infeasible in that it takes a long time |
| 17:07 |
erle |
or the resolution is bad |
| 17:07 |
erle |
either or |
| 17:09 |
muurkha |
I wrote that in 02007 before WebGL or actually even Chrome, so it was pretty slow |
| 17:10 |
muurkha |
you can usually get by with bad resolution with any of these four algorithms by adding some kind of interpolation/extrapolation |
| 17:10 |
muurkha |
if you're drawing a square for each point with a point cloud, for example, fill the square not with a solid color but with a gradient |
| 17:11 |
muurkha |
in classic scanline rendering this is called "Gouraud shading", you're probably familiar with it under that name |
| 17:11 |
muurkha |
but it can be applied in Whitted-style raytracing, SDF raymarching, and pointcloud rendering too |
| 17:14 |
muurkha |
automatic differentiation makes that kind of thing significantly easier to implement |
| 17:17 |
muurkha |
jonadab: roughly speaking the quartic solver in that file is about the same amount of code as the polygon rasterizer in JS I linked above. so on one hand, sure, a quartic solver is the same amount of code as a whole 3-D graphics engine |
| 17:19 |
muurkha |
but on the other hand that "whole 3-D graphics engine" was a hack I wrote one night in a hotel in Uruguay when I couldn't sleep |
| 17:19 |
|
jaca122 joined #minetest |
| 17:20 |
muurkha |
I think it's reasonable to say that solving a quartic in closed form is extremely nonobvious if you set out to figure out how to do it from first principles |
| 17:22 |
muurkha |
because arguably the time from when people were solving, loosely defined, equations, to the time when someone finally figured out a closed-form quartic, was probably about 3500 years (02000 BCE to 01545 CE) |
| 17:23 |
muurkha |
but you don't have to reinvent the solution, you can look it up in Graphics Gems V or Wikipedia |
| 17:24 |
muurkha |
you just have to implement and test it |
| 17:26 |
muurkha |
erle: what do you think? |
| 17:28 |
erle |
muurkha i think i should stop doing toy stuff and should help figure out this issue: https://github.com/minetest/irrlicht/issues/236 |
| 17:39 |
MTDiscord |
<luatic> oh no sfan5 is trolling erle back now |
| 17:39 |
muurkha |
I'm not sfan5 |
| 17:39 |
MTDiscord |
<luatic> indeed you are not |
| 17:39 |
MTDiscord |
<luatic> but that issue is by sfan5 |
| 17:39 |
erle |
luatic yes we now can have a shared “i am looking at this parser in-depth for the first time” experience to bond! |
| 17:40 |
MTDiscord |
<luatic> sfan5 fuzzed the TGA loader to demonstrate that there are buffer overflows |
| 17:40 |
muurkha |
it looks like a legitimate issue |
| 17:40 |
MTDiscord |
<luatic> it is |
| 17:40 |
erle |
surely it will be handled as well as the PNG issues in the past :D |
| 17:40 |
muurkha |
have you reproduced it? |
| 17:40 |
MTDiscord |
<luatic> the motivation behind it may be more interesting though ;) |
| 17:40 |
erle |
(i.e. “can wait until after release”) |
| 17:40 |
erle |
nah, TGA is so easy it will probably be easy to fix |
| 17:41 |
muurkha |
it seems like a good reminder that parsers for even extremely simple input languages can easily have exploitable vulns |
| 17:41 |
erle |
muurkha i am pretty sure everything in irrlicht that does input-handling is similar. it's spaghet |
| 17:41 |
erle |
i think i once fuzzed b3d |
| 17:42 |
erle |
also sfan5 fixed the issue i found with ”my tiny image file claims to be larger than your entire screen” |
| 17:42 |
erle |
(where you just go into the parts of the file with x and y values with a hex editor and do a little trolling) |
| 17:43 |
erle |
the issue is legit and i'll see what i can do |
| 17:43 |
muurkha |
you can repro? |
| 17:43 |
muurkha |
I haven't tried it myself |
| 17:43 |
erle |
no, but would sfan5 ever lie to me? :D |
| 17:43 |
erle |
i did not try yet, but asked for test case minimization |
| 17:44 |
erle |
and i'll dissect the first example by hand |
| 17:44 |
erle |
to figure out what this is |
| 17:45 |
muurkha |
I don't think he would lie to you, no |
| 17:46 |
erle |
the handler for the ECF_A1R5G5B5 is really fucking weird anyway |
| 17:47 |
|
kamdard joined #minetest |
| 17:50 |
|
kamdard joined #minetest |
| 17:51 |
MTDiscord |
<luatic> looking at the reader, it seems to lack checks in various places; it's rather naive |
| 17:53 |
MTDiscord |
<luatic> for example there is no overflow check for s32 imageSize = header.ImageHeight * header.ImageWidth * bytesPerPixel; |
| 17:53 |
MTDiscord |
<luatic> no validation of pixel depth before using its value to calculate bytesPerPixel |
| 17:54 |
erle |
luatic all irrlicht code is like that |
| 17:54 |
erle |
written before LANGSEC was a thing |
| 17:54 |
|
kamdard joined #minetest |
| 17:54 |
erle |
i'd suggest to throw a bunch of assertions all over the place |
| 17:54 |
erle |
this is what i do in tga_encoder |
| 17:54 |
erle |
(btw, the rest of the engine should also be littered with assertions) |
| 17:54 |
MTDiscord |
<luatic> yeah, parsers should be littered with assertions |
| 17:54 |
|
Alnotz joined #minetest |
| 17:55 |
erle |
luatic, actually they should not, they should just be correct lol |
| 17:55 |
erle |
“if i were a programmer, i would just simply not program bugs. it's that easy!” |
| 17:58 |
MTDiscord |
<luatic> erle: I don't use assertions solely to assert program consistency (i.e. that I haven't made an error). |
| 17:58 |
MTDiscord |
<luatic> In my pure Lua PNG reader, I use assertions to assert that the input is valid. It's just syntactic sugar for a conditional throw in the end. |
| 18:00 |
erle |
read 7 turrets of babel if you have not |
| 18:00 |
erle |
but yeah i do the same when i am in a hurry or lazy |
| 18:00 |
erle |
(i.e. proof of concept code or tga_encoder lol) |
| 18:01 |
erle |
the problem is that you mix business logic and validation that way |
| 18:01 |
erle |
which is shitty to untangle if you do anything *else* than quit |
| 18:01 |
erle |
and shitty to backtrack from if your business logic has already done a business |
| 18:03 |
MTDiscord |
<luatic> I think I can mix it and still be safe for the most part. I'm not sure separation is worthwhile. |
| 18:04 |
MTDiscord |
<luatic> A well written recursive descent parser implicitly ensures that the input matches a context-free grammar. |
| 18:04 |
erle |
luatic muurkha i have a theory https://github.com/minetest/irrlicht/issues/236#issuecomment-1724119734 |
| 18:04 |
erle |
“I think I can mix it and still be safe for the most part. I'm not sure separation is worthwhile.” → try it, you safe a lot of work by separating it |
| 18:04 |
erle |
funnily, almost everyone's instinct is that it is more work |
| 18:05 |
erle |
but once you validated the input, you can write code that only ever has to work for the happy path |
| 18:05 |
erle |
which is a real time-saver |
| 18:05 |
|
qqq joined #minetest |
| 18:05 |
erle |
context-sensitivity in the palette entries makes sense: you can not sensibly refer to more colors than you have |
| 18:06 |
muurkha |
luatic: I think it's pretty appealing to generate your parser with a parser generator that also generates a proof witness for something like PVS |
| 18:07 |
muurkha |
but there's not a lot of parser generators out there done like that |
| 18:33 |
|
v-rob joined #minetest |
| 18:47 |
|
Sobinec joined #minetest |
| 18:47 |
erle |
muurkha luatic i may have solved the case! https://github.com/minetest/irrlicht/issues/236#issuecomment-1724184258 |
| 18:54 |
|
Sobinec joined #minetest |
| 18:57 |
erle |
luatic it seems to me the underlying issue is a naive colormap converter. can you maybe figure out if a synthesized PNG image with illegal colormap entries can also trigger this thing? |
| 19:00 |
MTDiscord |
<luatic> erle: in libpng i trust |
| 19:00 |
erle |
i think you misunderstand |
| 19:00 |
erle |
i did not ask you for your religios beliefs |
| 19:00 |
erle |
but for some real practical heresy |
| 19:01 |
MTDiscord |
<luatic> this heresy is so shrimple that there must have been a heretic who found it already |
| 19:01 |
MTDiscord |
<luatic> libpng is not some random code some jon contributed to irrlicht because he felt like it |
| 19:02 |
erle |
i take this as “no one will ever find a vulnerability in established code ever” |
| 19:02 |
MTDiscord |
<luatic> erle: not a vulnerability as simple as this, no |
| 19:02 |
erle |
i suggest you look at the things that afl fuzz found |
| 19:02 |
erle |
software was a mistake |
| 19:02 |
MTDiscord |
<luatic> indeed |
| 19:02 |
MTDiscord |
<luatic> use modlib's png reader |
| 19:02 |
erle |
i mean in general |
| 19:02 |
MTDiscord |
<luatic> yes |
| 19:02 |
MTDiscord |
<luatic> we're unable to produce bug-free code |
| 19:03 |
erle |
no we are able, but unwilling |
| 19:03 |
erle |
it is a) not fun b) not profitable |
| 19:03 |
MTDiscord |
<luatic> even the guys who worked on the Space Shuttle code still had a few bugs creep in |
| 19:03 |
MTDiscord |
<luatic> (but remarkably few!) |
| 19:03 |
erle |
as far as i know, the apollo guidance computer was bug free? |
| 19:09 |
|
luk3yx joined #minetest |
| 19:09 |
rubenwardy |
didn't they need to consistantly reset the computer to land in Apollo 11, as there was a bug |
| 19:09 |
rubenwardy |
faulty alarms |
| 19:12 |
|
sparky4 joined #minetest |
| 19:14 |
muurkha |
the AGC was definitely not bug-free |
| 19:14 |
muurkha |
but there has been bug-free software: seL4, CompCert, Integer BASIC |
| 19:18 |
muurkha |
erle: congratulations! |
| 19:19 |
muurkha |
libpng has had a lot of CVEs in it in the past and will probably have more in the future |
| 19:34 |
erle |
muurkha luatic please extrapolate your onions https://github.com/minetest/irrlicht/issues/236#issuecomment-1724250453 |
| 19:44 |
|
Izaya joined #minetest |
| 20:01 |
|
gxt joined #minetest |
| 20:23 |
|
imi joined #minetest |
| 20:29 |
|
v-rob joined #minetest |
| 20:31 |
|
sparky4 joined #minetest |
| 20:34 |
erle |
rubenwardy is there a better way for mods to contain nothing but a font than this? https://notabug.org/minetestia/pixel_fonts/src/main/init.lua |
| 20:34 |
erle |
the issue here being that people need to exit the world |
| 20:35 |
erle |
i ask because since unicode_text there is now the situation that the in-game font might not be able to render stuff that can be shown on a sign |
| 20:35 |
rubenwardy |
No, as font media isn't supported yet |
| 20:35 |
erle |
so i am thinking about providing a unifont + unifont CSUR mod |
| 20:36 |
erle |
well, if it is supported, i bet it will lead to a lot of funny exploits, unless it is strictly limited to stupid formats like hex or bdf |
| 20:36 |
erle |
i mean possibly even then haha |
| 20:37 |
muurkha |
pixel fonts could be supported a lot more safely than TrueType |
| 20:37 |
erle |
that's what i said |
| 20:38 |
erle |
(essentially) |
| 20:38 |
erle |
i think ttf contains programs muurkha? |
| 20:38 |
muurkha |
kind of |
| 20:38 |
muurkha |
but being a pixel font is no guarantee of safety, as we've seen in the above TGA bug :) |
| 20:38 |
erle |
pixel font rendering was removed though. it lead to a dependency on xml parsing! |
| 20:38 |
erle |
the code path in that TGA bug is more-than-fishy |
| 20:39 |
erle |
i think i kinda get why many game engines just accept 24 bit or 32 bit tgas |
| 20:39 |
erle |
and don't bother with palette or RLE shenanigans, but just apply le zip |
| 20:40 |
muurkha |
yeah, it probably does a fine job |
| 20:40 |
muurkha |
especially if you Paeth-predict the TGA first |
| 20:40 |
erle |
well then you can just use png (with all the associated baggage) |
| 20:41 |
muurkha |
that would be similar in some ways, yes |
| 20:41 |
muurkha |
but not in others |
| 20:43 |
erle |
i wonder why the checksums in PNG |
| 20:43 |
erle |
it makes it harder to fuzz |
| 20:43 |
erle |
and what are you gonna do, except stopping? |
| 20:44 |
muurkha |
the checksums in PNG are because a clear error message is a better way to handle data transmission or storage errors than producing incorrect ouptut |
| 20:44 |
erle |
yeah but why have it per chunk |
| 20:44 |
erle |
like you could have put it at the end |
| 20:45 |
muurkha |
in theory you could retry the download earlier, but I don't know if anything ever did that |
| 20:45 |
erle |
especially iEND or how it is called always has the same checksum |
| 20:45 |
muurkha |
can you hack some special-purpose checksum-calculation logic into your fuzzer? or is it not format-aware enough? |
| 20:46 |
erle |
you probably can, do you know afl? |
| 20:46 |
muurkha |
not really, only by reputation |
| 20:46 |
erle |
it has this funny visualization tool |
| 20:46 |
erle |
one sec pls |
| 20:46 |
muurkha |
also you could hack libpng to disable the checksum checking, and then if you get a crash in the fuzzer, you can probably fix up the checksums by hand and get something that crashes real libpng |
| 20:48 |
erle |
muurkha https://lcamtuf.blogspot.com/2016/02/say-hello-to-afl-analyze.html |
| 20:48 |
erle |
afl will show you where it has difficulties (suspected checksum) |
| 20:48 |
erle |
and yeah, hacking the libpng is prob the idea |
| 20:50 |
erle |
at work many years ago i used afl just for one thing: to find bugs in code that dealt with exif data |
| 20:50 |
erle |
like, load a jpeg, examine the exif data |
| 20:50 |
erle |
turns out there are a lot of ways that can go wrong! |
| 21:06 |
MTDiscord |
<luatic> heh |
| 21:07 |
MTDiscord |
<luatic> anyways yeah i assume the checksums (and also all the other overhead) make more sense if you think of png chunks as packets to be sent over a network |
| 21:20 |
|
v-rob joined #minetest |
| 21:29 |
muurkha |
or a modem |
| 21:53 |
erle |
luatic muurkha but that layer already has checksums, or not? |
| 22:30 |
muurkha |
sometimes |
| 22:31 |
muurkha |
a bit flipped in my on-disk copy of Firefox once, it would segfault when opening certain web pages |
| 22:31 |
muurkha |
I was excited when I tracked it down in GDB, I thought I had found a potentially exploitable vulnerability |
| 22:32 |
muurkha |
well, I had, but only in my copy of Firefox. debsums showed me it was corrupted. reinstalling the .deb fixed it |
| 22:32 |
|
panwolfram joined #minetest |
| 22:32 |
muurkha |
the disk didn't have checksums at all (it was a 1-bit error, literally any common checksum would have caught it, even a parity bit) |
| 22:33 |
muurkha |
also TCP checksums are pretty weak; if your network cable is introducing a lot of packet errors, TCP can paper over it with retransmissions |
| 22:34 |
muurkha |
but one out of every 65536 randomly corrupted packets will pass TCP's checksum, and potentially a lot more than that with certain patterns of bit errors |
| 22:36 |
muurkha |
if 20% of your packets arrive corrupted (and have to be retransmitted) and you're using 1500-byte TCP segments, you'll have an undetected transmission error once every 490 megabytes |
| 22:36 |
muurkha |
that undoubtedly sounded like an inconceivably large number when they were designing it in 01978 |
| 22:37 |
muurkha |
PNG doesn't have automatic retransmission, so checksums at the PNG layer are much less likely to silently hide data corruption that way |
| 22:45 |
|
nm0i joined #minetest |
| 22:50 |
erle |
i once had a bit flip and it changed the case of a letter |
| 22:50 |
erle |
this tought me something about ASCII design haha |
| 22:51 |
erle |
it was in a config file |
| 23:06 |
muurkha |
heh |
| 23:48 |
|
sys4 joined #minetest |
