ux

Thank you for the kind words, and you're on point with "poetry using math".

I started 2-3 months ago or so doing this stuff, so don't be too intimidated to start. Especially with the two articles (Red Alp and this one), it should make it more accessible, hopefully :)

Thanks for putting this together.

I'm glad it reaches an audience :)

Only critique is.. if you're sharing to teach, your compact/one line [460] char GLSL code is a poor delivery mechanism.

Understandable. Though, the demos are here to illustrate "what you can do with the trick I'm sharing". It's like, I'm teaching you how to do watercolor, and illustrate it with some paintings you won't be able to perform just with that knowledge. They're meant to inspire you to create. You're not looking at a tutorial, you're looking at art.

What's a good way to get started learning to build/customize shaders with GLSL?

I gave some directions and resources in a comment here, it might help you: https://www.reddit.com/r/GraphicsProgramming/comments/1pgqis...

And GLSL syntax looks a bit tedious to be honest, but I'd love to dive in.

With the vectorization everywhere, it's surprisingly convenient given how simple the syntax is. I personally just miss some sinpi/cospi/etc, and/or a PI and TAU constant.

Thank you! Do we have a guarantee that these subcurves are solvable with Newton's method? The approach with derivatives has this because we know there is one crossing, and also clipping them to the zero-derivatives makes sure there won't be multiple curve "pits".

What you described in your first message seemed similar to the approach used in the degree N root solving algorithm by Cem Yuksel; splitting the curve in simpler segments, then bisect into them. I'd be happy to explore what you suggested, but I'm not mathematically literate, so I'll be honest with you; what you're saying here is complete gibberish to me, and it's very hard to follow your point. It will take me weeks to figure out your suggestion and make a call as to whether it's actually simpler or more performant than what is proposed in the article.

Thanks, I'll look into this. BTW, your 2nd shadertoy link is off (maybe it's private? Edit: seems you fixed it, thanks)

I'm interested in the approach you're describing but it's hard to follow a comment in the margin. Is there a paper or an implementation example somewhere?

Finding the sign of the distance has been extremely challenging to me in many ways, so I'm very curious about the approach you're presenting. The snippet you shared has a "a³-bcd ≤ 0" formula which is all I get without more context. Can you elaborate on it or provide resources?

The winding number logic is usually super involved, especially when multiple sub-shapes start overlap and subtracting each other. Is this covered or orthogonal to what you are talking about?

Ah nice for noticing d!=0 is d>0. Not sure how I missed the multiplication to get rid of the vector form; I guess I was too obsessed with the x-x trick...

I added your changes to the Shadertoy version with your HN nickname. I'll integrate it to the original later.

Thanks!

Is this tutorial kind of abandoned? There are many teased chapters that never seem to have materialized somehow.

This is not equivalent; the `a` in `c.r+=w*a` is different, you need the original untouched w. The mountain looses its crack with your version.

But! You can save 1 char by replacing w with a:

    g -= a*=w,
    c += a*d*9.+...
    a = min(...),
    c.r += w*a*a*.2,

Incredible, thank you very much. I've included the script for a quick fix, I'll see how to make to cook something myself at some point!

Yeah. If you want implicit conversion, you need to specify a constructor like float(cond), but that would be longer than the ternary form. I thought about using a vec3() but vec3(...).x is still too long and using the vec3 directly doesn't look viable. Declaring a bool adds more characters as well. There is also step() giving the same number of chars: a=step(.001,h), but it's not more optimal: https://iquilezles.org/articles/gpuconditionals/

If you see a way to make it shorter, feel free to share :)

Ah, someone reported this to me today, but I must admit I have no idea how to address the issue. Currently the canvas animations are stopped when out of context, but yeah they have to be loaded.

The code on the blog is pretty simple and naive (I'm not a webdev): https://github.com/ubitux/scripts/blob/main/share/blog/shade...

Any suggestion on how to address the issue is welcome.

Note: I don't have any Windows machine to test with

Hey, thank you, that's a nice one. I added the change to the Shadertoy version with your credit. I will add a note/update on the blog and demo page later. Thanks again :)

Hehe, thanks. The thing is, it could hardly have been prerecorded animations :D

I don't know if you tried before, but compressing noise is particularly hard, so 16 videos would have been quite too much of bandwidth. The total size of the shaders is something around 70kB (not minimized) for endless lossless videos, and since I had to write them anyway if I were doing records of them, it was really a no-brainer to embed them to be honest.

What an impressive and thorough deep dive.

Thanks!

Have any of you ever gotten lost tweaking fade functions to get that perfect wave-like look?

You cannot use anything for the fade function, because you likely want the derivative (and potentially the second derivative) to be 0. See https://gist.github.com/KdotJPG/417d62708c76d53972f006cb906f... for making different ones. I personally never tried anything else than the hermite and the quintic.

1. depends if you're in the physics main loop or not; in Godot for example the physics main loop is based on the project configuration, not correlated with the display (I could have expanded on that in the article)

2. You can know the targeted frame rate, you can also infer it by averaging the delta times at runtime (not reliable but maybe more accurate on a slow machine?)

3. In my graph, I did pick random delta between 15 and 120 fps IIRC; the point was to simulate what could roughly happen with random lag spikes

That's some very good recommendations you made here. I'm adding all 3 at the end, thank you.

Only the exp call happens in the processing loop. The ln is in the conversion function, it's not supposed to land in the code.

As the delta time converges to 0, the lerp coefficient is going to converge to 0 as well, meaning it won't move. Said differently, if time stops the interpolation as well. You may enter into the realm of floating point accuracy issues at some point with low values, but I'm curious of what specific scenario you have in mind here?

A frame time spike is covered by the overshooting point: it will basically land further down the curve, which means a point converging toward the B target.

We've just released a new version of Nope Foundry yesterday: https://www.nope-foundry.org

You might want to have a look.

Video, Images, Rich Text and Animations are typically what we strive for. Check out maybe https://nopefoundry.github.io/nope.gl/usr/howto/renders.html and the other howtos.

Note that the history.md is going to be removed soon from the repository since it's been integrated as-is within the website (see the /about page)

One thing you can do as a user already today to reduce Python dynamism of classes is using __slots__: https://wiki.python.org/moin/UsingSlots. I enjoy this a lot, not only for the memory and access performance boost, but because it also makes the code more rigid (and thus more resilient to monkey code attacks).

This thread from @jonsneyers about VMAF choking is quite entertaining: https://twitter.com/jonsneyers/status/1573371624132419585

Author's here.

I'm not sure why this is posted here, but please note that this was written more than 10 years ago, and a lot of things changed since then. It's important to take this article from an historical perspective, keeping in mind that it was written by someone with "interests" in the matter (as much as I wanted to be objective, let's not lie to ourselves, I was a FFmpeg developer first). The popularity of this article played an important role in "public's opinion" (it's my most popular article ever).

Nowadays, even though I've been distant to the project for years now, I can say the situation changed in a good way (from my perspective). The projects are unified again because people from both sides made difficult compromises. I think it would make sense to focus on how the issue was resolved rather that why it was so bad. This fire is extinguished, let's work on keeping things as peaceful as we can.

For the record, I mostly left FFmpeg development years ago. And while it wasn't the only factor, the merge effort and overall tension actually drained me pretty badly at that time. Of course, this is also true for several people from both sides, and surprising to no one the project(s) lost many developers in the process.

The multimedia community is plagued with drama like this, but this one was particularly destructive. We can certainly take lessons from this, but I'll leave that to the historians.

Thanks, yeah the visualization was fun to do. I'll eventually try to cleanup the script I did in a hurry and submit to the research repo along with the others.

WRT to the viewport mess on mobile, I'm not sure what's going on. I did set the width=device-width thingy in the header, and the <video> has a width of 800 (container is 900), but it doesn't seem to honor that for some reason. Webdev definitely isn't my thing, so I haven't looked into it much yet. If someone has a suggestion I'm happy to give it a chance. The same happened in the Bézier article I wrote a while ago, and I agree it's annoying.

Blending done in perceptual (sRGB) space

Oh please don't say that. The sRGB transfer function may be somehow roughly correlated with how we perceive lightness, but it's in no way a perceptual space.

Floating point operations are not deterministic in other situations: https://randomascii.wordpress.com/2013/07/16/floating-point-...

This can be terribly hard to manage in tests if you don't have a threshold infrastructure in place (which is hard and sometimes impossible to setup if you don't want to preserve huge references).

Also, and this is a bit off topic, even if I remained in the float domain for my use case, I would have to re-implement the lib math routines anyway (in my case cbrt and pow) because they are not implemented the same in all the libc, making them again victim to non determinism.

So far I observed better performance with integer arithmetic anyway, but that's not the reason that motivated me.

Also note that there are other situations were you may want to keep integers; typically in the kernel, or on arch were the floating point is not optimal or even available.