An introduction to Shader Art Coding

This is probably the best shader introduction in YouTube. It's very informative and it's also less than 30 minutes.

I thought the vocal track sounded just slightly disjointed, then I saw that you used AI to generate it. Very neat way to communicate when you're not totally comfortable with your own voice. Had you not said anything in the description, I'd probably think you were either uncomfortable recording voiceovers, or had hired someone to do it from fiverr. Very good video!

You don't need a graphics card to run shaders, just a GPU. This is such a good tutorial, seriously next level. By far the coolest coding tutorial I've ever seen, hands down.

So you drop this absolute banger of a first youtube video and go dark for months at a time? What a madlad

Wow. WOW I'm blown away by this tutorial. I can't BELIEVE how well this is made, and how well you explained this subject. Even as a coder (as a hobby), shader coding has always been this gigantic terrifying unknowable thing, and half an hour later it feels so down to earth and doable. Here's a like, Here's a sub, here's a comment. More shader content please !

This video is a masterpiece. It should be everyone's first stop when learning shader code.

This is the most productive 22:30 minutes of my life. I wish every tutorial could explain such difficult concepts in such an engaging way.

No, I did not notice the voice was AI, only that it was polished and articulate. This is one of the most fascinating YT videos I've watched. All the more so because I only barely understood most of it—but did understand some of it. I'm 75 years old and have no experience with coding except for a thorough understanding of HTML, and a basic knowledge of JS and CSS. My original background and training are in the fine visual arts—i.e., predigital age, hands-on drawing, and painting with RW physical materials. That said, I've lived in the SF Bay Area for most of my adult life, occasionally rubbing shoulders with more technically-minded peers. Even so, I had little interest in computer technology until the mid-to-late 1990s when the internet came along. Before that, from the mid-1980s, although I had played around a little with visuals on what were then high-end systems belonging to friends who were more into emerging digital arts, I couldn't take them seriously. In those days, the only way to show anyone a digital image was to put it on a floppy disk and boot it up on someone's system. OR—Alternatively—take a 35mm film SLR photograph of the image on the highest resolution monitor available, then have the film processed and a print made from the film. — IOW, the way I saw it, there was no way to share the digital image produced with a mass audience in the medium in which it had been created. The internet changed all that as it was now possible to share digital images globally. Thus it was only then that I began to take digital imaging more seriously as an art form. It still remained more of a 'novelty' to me than something I regarded as a 'genuine' art. Along the way, I bought my first Apple/Mac system, began learning Adobe Illustrator and Photoshop, and discovered I had an aptitude for HTML (that was a big surprise). This was in the days when we wrote it by hand in MS Word, saving it in a .text format—then opening the .html in a browser. This led to a grasp of hexadecimal color values, and, later the addition of CSS and a sufficient sprinkling of JS to (at least) be able to modify code someone else had written—to adapt an JS slideshow on a web page, for example. The small publishing company I worked for at the time (1996-98) was sufficiently impressed with my skills that they wanted to send me up to Seattle for further training. But I refused this generous offer because, bottom line, I was a fine arts painter who only worked a job to support his art (large, up to 8x10 feet, very visceral—action based— abstract paintings) and did NOT want my attention to become absorbed by the non-physical digital realm of emerging AR, etc. The way I thought about it at the time was, "The ability to a) modify a digital image with infinite iterations, and b) infinitely distribute reproductions of those iterations as visual impressions, reduced any inherent value of that image to absolute ZERO. " I still feel that way today! LOL But, putting all philosophical questions regarding the "inherent value" of any image aside, this initial tutorial is fascinating! I didn't understand a lot of it (math skills stagnated at high school level Algebra II—Trig seemed beyond my comprehension and was of no interest whatever) but I understood enough. I already understood that pixels are like cells in a spreadsheet, and that image editing apps were performing mathematical operations on those cells —but now I FINALLY have a glimmer of understanding of what a vector (as in vectors drawn in Illustrator) *is*. If I were 15 or even 25 and not 75 years old I'd probably be all over this, flinging my time and attention into fine-tuned digital image generation at the coding level! But as it is—I think I've had quite enough of this world already. I'll leave it to you youngsters to wander off into the virtual realm, and over the cliff of infinite iterations, of the emerging all-mighty (oxymoronic) AI. All I'll add is, "GOOD LUCK" — you're gonna need it!

I always wanted to take a deep dive into shaders but never took the time to do so. Thank you so much for providing such a brilliant introduction.

Are you a friggin wizard genius savant? Because until today I had absolutely zero understanding of this art and only ever appreciated it. Today I can write it. And its entirely due to your 20min video. I'm beyond amazed. Further, the most perfect metering, speech, explanations, volume, calmness, and even lofi background music. The production value and quality of this video is 10x what I've seen or learned from in life. I never comment.

This was such a great video. It definitely makes me wanna dive into it. I also love and appreciate the final statement as sometimes even with regular coding, we don't take the time to appreciate what we've built already because we're so focused on what it is we need to build. Love the content. Subscribed !

This is such an unbelievably concise resource containing everything needed to get started, along with being so well presented. Massive props, thank you

God tier tutorial, absolutely unreal that this is the first video on your channel. This is where production quality and planning goes from being a comfort to being a legitimate pull for new people to the subject you’re covering. Mega cheers dude.

I have a bunch of experience making photorealistic pathtracing shaders but I've always lacked the reasoning for creative projects like these. This was super helpful thank you

I’ve never thought of shaders being used artistically like this, just for games. Fascinating and illuminating to see maths meet art like this- the results speak for themselves.

What an absolutely incredible tutorial. I've ALWAYS struggled with learning shaders, having tried on several occasions, and the quality of this tutorial alone puts others to shame. If this is an indication of the level of clear, concise, and effective communication one can expect from this channel, then you've got a new subscriber. Cheers, and thank you so much!

Thank you, this kind of shader art or math art tutorial is really cool! One small note: at 13:20 (and throughout the rest of the video) when you multiply the argument of sin() by 8 and divide the result by 8, you are multiplying and dividing different things. Multiplying the argument by 8 increases the frequency, which is what gives multiple rings. But dividing the result by 8 only has an effect on the amplitude of the resulting sine wave, which will oscillate between -0.125 and 0.125 instead of -1 and 1. So you might have just kept the oscillation between -1 and 1 and adjusted the argument to smoothstep(). Further on, at 15:05, in the same way you can remove the division by 8 and adjust the coefficient of the inverse function (0.16 instead of 0.02) The reasons for doing this would be 1. to avoid any confusion that the two 8 in sin(d*8.)/8. have any relation to each other (they don't, except for keeping the derivative close to ±1 when the sine wave crosses the x axis, which doesn't have much use in this case because you're inverting and scaling the resulting value anyways) and 2. to avoid division, which is still a costly operation in hardware, hence the fewer divisions you perform, the faster your code will be. Check out Quake III's famous Fast Inverse Square Root algorithm for an example of the effort programmers will do to avoid dividing numbers.

What a fantastic production. You absolutely nailed that delivery. Thankyou!

The combination of code and math resulting in such beautiful visuals is wonderful

This is honestly one of the best tutorials i've come across. Period. Amazing view into a topic i was only mildly familiar with and broke it down in very approachable and informative ways. The illustrations showing everything as code was updated really blew me away! Great work.