Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interactive intro to shaders

mayerowitz.io

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Interactive intro to shaders

#51

Post by bazzargh »

rendaw wrote: post #10
superMayo wrote: post #2

I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.

Tangential to the main topic, what generative art artists are you following and/or where did you look to find them? I found a couple myself (@D_VISION7 @lv374 @beesandbombs @HAL09999), but ran into roadblocks trying to find more. There are a few fractals here and there, etc. Shadertoy seemed mostly like math demos/challenges rather than art, or at least it doesn't have an easy way to find the artsy ones.

On mastodon you can follow hashtags, so follow #generative, #procedural, #creativecoding etc, not just people; you get a lot of serendipitous finds this way. What shows up on the different tags varies a bit: #generativeart picks up a lot more AI-generated guff, not interesting to me at all, while #generative tends to get less of that and more hand-coded art.

I do find a lot of NFT pollution in these tags so I've got words related to that filtered out.

I follow some actual people too and you can find good follows from who they RT but following tags made mastodon much better for me than t**ter ever was, and actually makes it worthwhile posting with tags.

Re: Interactive intro to shaders

#52

Post by habibur »

superMayo wrote: post #48
habibur wrote: post #46

In case anyone else was seeing the images as flickering noise, my fix was to copy the image from the browser and paste those somewhere else. You can view the images correctly. Link to imgur. The first image is screenshot of what I see in the browser. The rest are actual images after pasting to imgur. https://imgur.com/a/F4203rz

That's strange, what browser are you using?

Chrome / Fedora 38 64 bit / Wayland / Radeon Vega 3 graphics.

Re: Interactive intro to shaders

#53

Post by EmilioMartinez »

Draiken wrote: post #42

I have never dealt with shaders, so pardon me if it's a very basic question. In a single frame from a game, are shaders essentially all that are being used to draw it? Or do we have basic shapes like triangles, squares, circles, etc and the shaders go on top of it, drawing shadows, smoothing edges, etc? From the example, it seems like you can create a shader to draw any object in a scene, and then I imagine you compo…

Yes, you got the right idea. AFAIK every type of code running on the GPU is called a shader (eg. special data operations are even called "compute shaders", although they are a different beast). All the operations you mentioned (colors, shadows, shading, image-effects, general image-processing) are achieved through parallelized computing combining lots of data arrays (vertices and their properties, source textures, pre-computed functions, target textures, buffers, etc).

For example, to get light and shadows, your shader should have access to some (probably global) variable about the position and direction of eg. a spotlight. Very often composite lighthing is achieved by combining multiple shader passes (a base pass for global ilumination, and one for each light for example), each literally adding more light (additive pass). Now, in order to avoid adding light for pixels where the light source is blocked (ie. shadow) the most common technique is using what's called a Z-buffer (just a floating point texture). You want to know for each light in the scene where their light reaches, so (before all lighting is applied) you set up a single shader pass that combines all solid geometry on the scene and using the light position and direction as the camera transform, and use a special shader whose only purpose is writing the objects distance to the Z-buffer. Now, every time you want to know whether a point in space is reached by your light, you go about sampling this Z-buffer (after doing some geometry) and compare the point's distance to the saved value in that direction. Yes, it can be very buggy and precision errors abound, and every engine worth their salt already does this for you, but lets you get in there and modify the process.

Everything else are variations on this theme. Deferred rendering is rendering data instead of colors into an intermediate texture which is later processed to get the colors. Blur effects are 2D convolutions of the rendertexture (eg by a Gaussing kernel). Tesseletion shaders are about generation new geometry in the vertext shader. Even drawing text is achieved through font atlasing and small rectangles.

Re: Interactive intro to shaders

#54

Post by pjc50 »

superMayo wrote: post #2

I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.

The Mona Lisa paint cannon is an incredible GIF, do you know where that's from?

Re: Interactive intro to shaders

#55

Post by pjc50 »

Draiken wrote: post #42

I have never dealt with shaders, so pardon me if it's a very basic question. In a single frame from a game, are shaders essentially all that are being used to draw it? Or do we have basic shapes like triangles, squares, circles, etc and the shaders go on top of it, drawing shadows, smoothing edges, etc? From the example, it seems like you can create a shader to draw any object in a scene, and then I imagine you compo…

> Or do we have basic shapes like triangles

Generally this - the SDF mechanism is very clever, but that's not what game engines tend to do, their geometry comes from triangle-based tools used by artists.

Re: Interactive intro to shaders

#56

Post by TheMaskedCoder »

pjc50 wrote: post #54
superMayo wrote: post #2

I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.

The Mona Lisa paint cannon is an incredible GIF, do you know where that's from?

Looks like it's from a talk the MythBusters guys did at NVISION 08: https://www.youtube.com/watch?v=aa3OGgBkRiQ

Re: Interactive intro to shaders

#57

Post by haspok »

superMayo wrote: post #2

I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.

First sentence: "What if I told you that it could takeS..."

You might want to correct that. Now reading on :)

Re: Interactive intro to shaders

#58

Post by flakes »

sph wrote: post #37
superMayo wrote: post #2

I finally found the courage to write and expose myself to the internet. I've always wanted to learn shaders so I thought it would be nice to document my learning and share it with others.

Welcome to the Internet, superMayo! If you want to see what the Masters can do with shaders, let me introduce you to Inigo Quilez and his shader art: https://www.youtube.com/watch?v=BFld4EBO2RE EDIT: I did not notice you are the author of this article. It's very well done, and I've been looking for more approachable and interactive tutorials on the arts of shader coding.

That was an amazing video, thanks for sharing! I really appreciate that there's a link to the shader code as well. Makes me want to dive into graphics again!

Re: Interactive intro to shaders

#60

Post by Sharlin »

Draiken wrote: post #42

I have never dealt with shaders, so pardon me if it's a very basic question. In a single frame from a game, are shaders essentially all that are being used to draw it? Or do we have basic shapes like triangles, squares, circles, etc and the shaders go on top of it, drawing shadows, smoothing edges, etc? From the example, it seems like you can create a shader to draw any object in a scene, and then I imagine you compo…

(Note the following is a simplified description of the classic forward rendering process; the so-called deferred rendering techniqure is a bit different.)

A GPU turns an abstract vector shape like a triangle, defined by three vertices and data such as a normal associated with each vertex, into a stream of fragments, one (or more if multisampling) for each pixel in the output buffer that’s covered by the shape. This part is all done in hardware.

A fragment is a pixel coordinate plus user-supplied data that’s either constant, called uniform, or the aforementioned vertex data interpolated across the triangle face, called varying. This interpolation business is again done in hardware and not programmable.

The fragment shader takes a fragment as input and based on the data computes a color, which is (after a couple more stages) output on the screen (or offscreen buffer) as the color of the respective pixel. This could be anything from a constant color to complex lighting calculations. In GPU rendering, this is all massively parallel, with countless fragments being processed simultaneously at any moment. Shaders are pure, stateless functions: the only data they can access is the input, and the only effect they can have is to return a color (and a few other things like a depth value).

So in a nutshell, the GPU hardware is responsible for computing which pixels should be filled to draw each triangle, but the fragment shader’s responsibility is to determine the color value of each of those pixels.

Post reply on HN