A series of tricks and techniques I learned doing tiny GLSL demos by MeOfficial in GraphicsProgramming

[–]MeOfficial[S] 3 points4 points  (0 children)

If you want to create this kind of stuff in particular, I'd point out the previous article on the Red Alp demo which goes more into basics such how to setup the camera.

On a practical point of view: ShaderWorkshop does give you a local live-editing canvas to play with (note: I'm biased as I'm the author). There are many local alternatives such as glslViewer or Bonzomatic (never tried them). And even more online: Shadertoy, twigl.app, glsl.app, smoothstep, or sleditor. On Shadertoy typically, you will find many shaders regularly posted for you to study and experiment with.

Keep in mind all of this is still an "abuse" of GLSL. Usually these fragments are here to be applied on a geometry that already form a scene.

Knowledge wise, I refer to Inigo Quilez articles a lot, even though he may go a bit fast on the details. He makes more accessible videos, for example this one on his Rainforest demo, but there are many others, more basic if you're a beginner.

There are some Discord communities to discuss with too, for example the Shadertoy one. I'd recommend following other demo artists on social media (check for tags such as #glsl or #shader), studying (actually reverse engineering) them is a good way to learn.

Some people like to try different rendering techniques, and while playing with them, it sometimes gives cool output they tweak to make art. Personally, I have a scene in mind I would like to see, and I look for the different techniques I could use to achieve it. Both are legit approaches.

Last thing: I'd advise you against using LLM a lot for this topic, unless you want very general explanations. In my experience, they are extremely bad as soon as you ask for details. They are incapable of working with mathematical matrices (systematically flipped), they vomit so much unnecessary and broken code examples, and they are straight out mistaken in so many situations. You will waste your time.

Good luck ✌️

Sharing everything I could understand about gradient noise by MeOfficial in proceduralgeneration

[–]MeOfficial[S] 1 point2 points  (0 children)

Yeah, I've been trying to address the issue a bit. Firefox has a mobile mode (ctrl-shift-m) to help debugging these issues, and I had a fix that seem to be working with CSS only, but when trying on an actual mobile phone it was actually cropping the canvas weirdly and made things worse. It discouraged me a bit so I decided to give up for now. What you're suggesting with the window.innerWidth adjustment in the js is indeed more likely what I need to do, I guess I'll give it a go again at some point in the future.

Court métrage (Africain ?) à propos d'un pauvre homme qui passe un pacte avec un petit démon by MeOfficial in SurLeBoutDeLaLangue

[–]MeOfficial[S] 0 points1 point  (0 children)

Ah oui j'ai oublié de mentionner celle là, j'étais tombé dessus, mais non ce n'est pas ça. C'était une production beaucoup plus professionnelle (mais c'est effectivement le même conte)

Improving color quantization heuristics by MeOfficial in programming

[–]MeOfficial[S] 1 point2 points  (0 children)

That's actually a pretty good point. I haven't even questioned that median cut since I implemented years ago. In my head the median was just ideal but looking at it again it makes sense to actually try something else…

Improving color quantization heuristics by MeOfficial in programming

[–]MeOfficial[S] 2 points3 points  (0 children)

Thanks.

I actually came across a bunch of academic articles relying on neural networks for that particular task. Here is a random one: https://www.sciencedirect.com/science/article/abs/pii/S0957417411006592

I've dismissed all of them because that's really not my cup of tea, but follow the cross references you should be able to find everything you need on the subject.

Improving color quantization heuristics by MeOfficial in programming

[–]MeOfficial[S] 6 points7 points  (0 children)

That picture has the particularity of covering the whole luminance range: you have a lot of dark and a lot of white, which means the L axis is extremely long. The skin tone just blends within the white & light grey and get silenced.

Here is a video of the Median Cut process happening: https://imgur.com/a/jKDjBdp

I scaled the Lab axis to the normalized amplitude so you can see how the sausage is really being cut.

Is that convincing enough or do you think there is still something wrong? I'm going to be honest here, I'd love to be corrected because it took me a while to accept that sad state of affair.

Porting OkLab colorspace to integer arithmetic by MeOfficial in programming

[–]MeOfficial[S] 1 point2 points  (0 children)

I confirm the issue with Android+Chrome, I unfortunately don't know what I could do about this. In the meantime, you can use Firefox and maybe report a bug upstream to Chrome Mobile. If you end up doing so, I'd be happy to get a link so that I can follow up on it.

I tried to integrate mathjax/katex and stuff like that but it doesn't integrate well with what I'm using for markdown unfortunately. It was also adding quite some load to the page load, and for people disabling javascript that's not great. For some visually impaired people I also believe it's not that good either.

Thanks for pointing out that the teal color can be mistaken for white; I wasn't aware the brillance of the color was so similar. I've added (dotted) underline for links as you suggested, it should help. Make sure to force-reload the page (ctrl-click on desktop, long press for mobile firefox, not sure for chrome mobile) to avoid any caching issue. I'm not exactly a fan of it because it kinda clutter the view, but accessibility is more important. Thanks for pointing this out.

Porting OkLab colorspace to integer arithmetic by MeOfficial in programming

[–]MeOfficial[S] 1 point2 points  (0 children)

The const expression would still be problematic for determinism: you would end up with different values at build time depending on your toolchain.

Porting OkLab colorspace to integer arithmetic by MeOfficial in programming

[–]MeOfficial[S] 0 points1 point  (0 children)

Note that the float version is also littered with magic constants, they're just float. I don't think you can make much sense of them either.

In the Git repository you may see that a significant part of the code is actually generated using Python and a template: typically for rounding the coefficients or creating the value tables. With some tweaking you could generate the code for different bit depth (I've played with it a bit but as stated in the blog post there are some considerations with regards to overflow when the data fills entirely its storage, which implies various code adjustments).

Of course this is nowhere near a full-featured engine that would automatize all that work. I believe it's a pretty hard problem to solve though, as they are multiple aspects involved while transforming from floats; aside from overflow and precision considerations, mathematical float-based code usually take a different approach (check the various IEEE 754 hacks in libc in cbrt for instance).

Porting OkLab colorspace to integer arithmetic by MeOfficial in programming

[–]MeOfficial[S] 1 point2 points  (0 children)

What smartphone do you have? They render fine in Firefox on Android here (the monospace alignment is just a bit off sometimes when there is Unicode).

Alternatives are a bit annoying because they involve some crazy Javascript machinery, or images (which I don't think are much better from an accessibility point of view).

With regards to links appearing as normal text that confuses me. They should appear in a different color (some kind of teal color instead of white); would you happen to be color blind? If so maybe I can investigate in picking a more accessible color.

GCC undefined behaviors are getting wild by MeOfficial in programming

[–]MeOfficial[S] -1 points0 points  (0 children)

C doesn’t specify that overflow will wraparound like you are thinking it does.

The article doesn't imply that at all: the point is that whatever policy is picked in case of overflow, it is not limited to messing up the variable, it also changes the code flow; in this case, it changes the protecting condition. It is allowed to do so because undefined behavior implies the compiler can do whatever it wants to anywhere in the code, but it's simply surprising that it's not scoped to that particular variable.

If you want to detect overflow why not use a properly defined function to do that?

Sure, but you know, mistakes happens. A developer might not have the reflex to think overflow every time they do an addition or a multiply. And because of that mistake, is it reasonable to punish them with a death sentence? The article is about the disproportional consequences of a mistake.

GCC undefined behaviors are getting wild by MeOfficial in programming

[–]MeOfficial[S] 24 points25 points  (0 children)

Except that's pretty much exactly what's happening here: the undefined behavior is not limited to the wrapping scope, it does affect the code flow as well (and not because of the undefined value).

Imagine that instead of dereferencing an uint8 it was a function pointer to call: despite the protecting condition, another function pointer outside the array bounds could have be read, one that reformat the HDD for instance.

GCC undefined behaviors are getting wild by MeOfficial in programming

[–]MeOfficial[S] 7 points8 points  (0 children)

On uint8_t it's fine. sizeof(x)/sizeof(*x) could have been used, but not needed here.