@@rutvikpanchal5726 well in that case you can square the radius instead of square-rooting the x^2 + y^2, this is beneficial cuz square (simple multiplication, one instruction) is way cheaper than square root computationally
I learned about such a Soft and Round circle rendering technique, in a book: "The Book of Shaders". Really good book for beginners (and not only) will help you in shader coding and understanding.
A "non-filled in circle" is called a circle. A filled in one is called a disk (It's actually more complicated than that but that's the simple explanation)
I just found your channel and it's awesome to finally find some premium quality Aussie content that's actually interesting as Zenva didn't agree with my ADHD.
Love the videos man, they're great to send to beginners; make sure you get up and get your steps in; gotta pay attention when you're working from home long term.
Throughout the whole video I was wondering how you were gonna make the edges smooth. I don't know if there are other, more efficient anti aliasing methods, but isn't it weird to have a anti aliasing function (=smoothstep) that depends on the number of pixels of the radius? Like, it you make the circle very small, you have to change the fade value, same if you make the circle very big. Maybe I don't have the right use cases in mind, but here's what I see: 1- UI: If you use your shader to draw a circle in the UI, then at least you'll always control how big or how small it is, so that's easier. But you still have to manually adjust the fade for each size of circle you have in your UI, and each resolution the game supports. Otherwise, the edge will either look too jagged or too blurry sometimes. 2- Gameplay: If you draw a circle in the 2D/3D world, the problems above are still relevant, but in addition to that, I suppose that the circle could change size dynamically due to gameplay events (distance to camera, growth/shrinking etc) So there seems to be missing, from this video, a way to make the fade value be proportional to the total screen resolution for each frame.
the smoothstep function has one draw back, if you increase or decrease the size of the circle you either get antialising again because the smoothstep threshold is to small or you get a blurry edge because the threshold is too big, a somewhat good alternative is to use the fwidth function to calculate the edge smoothing, since it uses derivatives they are "screen size" aware so it doesn't matter which size your circle is in the screen, the draw back is that it's a bit more expensive and derivatives uses 2x2 pixel blocks which in some shapes can be seen, it's not the case with circles tho not sure how derivatives work with shadertoy but the final code would be: distance / fwidth( distance )
It'd be cool if Hazel had full curve support in-runtime. Think of all the animations and blending you could do with them! There would definitely be some challenges, but if you can do it efficiently and simply, it would be awesome.
It depends, I have two different ways. My first method uses triangles, the number of sectors is determined by the camera distance, increasing the closer it gets. The second method uses the Bresenham circle algorithm. I can use this to draw pixels directly to a framebuffer or via a batch renderer where every pixel (for outlines) or every row of pixels (for solid) is a seperate quad. I didn't really have any concerns with the number of quads/triangles I was drawing as my batch renderer can ouput 1.7 million with a single draw call at over 70fps on my laptop and I don't tend to draw circles all that often for pixel games.
you could also create a geometry shader which is going to take point primitive as an input and turn those points into quads and then render the circles that way. If you use this you can then define the color and radius of the circle as a parameter in the vertex buffer
Something that works even better than a static "fade" amount is to scale it depending on the fragment size. In OpenGL 3, this is surprisingly easy to compute by using derivatives: const float sqrt2 = sqrt(2.0); float fade = sqrt2 * length(vec2(dFdx(distance), dFdy(distance))); This produces a pixel-resolution fade which works even when the quad is distorted. If you want an even crisper, but still antialiased, edge, you can use a linear smoothstep (which I call "lerpstep"). It is essentially the convolution of step() with a box filter. float lerpstep(float edge, float delta, float x) { float edge0 = edge - delta; float edge1 = edge + delta; return clamp((x - edge0) / (edge1 - edge0), 0.0, 1.0); } void mainImage( out vec4 fragColor, in vec2 fragCoord ) { // etc etc float distance = length(uv); float fade = length(vec2(dFdx(distance), dFdy(distance))); float alpha = lerpstep(thickness, fade, distance) - lerpstep(1.0, fade, distance); // etc etc }
Thanks for the code example! I never knew that dFdx and dFdy even existed before now. In case anyone was like myself and was quite confused about dFdx and dFdy, here's how I understand it: dFdx allows you to compare a variable of the current pixel being rendered to that same variable of the neighboring pixel to the left. Essentially the function returns the DIFFERENCE of a variable between two pixels that are horizontally right next to each other. This is useful because it tells us how much our variable changes per pixel which when rephrased, tells us how much we need to change our variable to get a pixel worth of width. dFdy is the same as dFdx except it compares pixels vertically instead of horizontally, so when a pixel is being rendered it'll look to the pixel above it to get the difference in their variable. Note this variable can be anything from user supplied varyings like uv coordinates, or variables like gl_PointCoord. Though you could supply a constant value like `1` to dFdx or dFdy but it would just return `0` as all pixels would just have the same value (as 1-1=0). Because we now know how much we need to change our variable to get a pixel worth of distance both horizontally and vertically, we can use it produce 1 pixel's worth of anti-aliasing which Pseudonym73 has shown above.
@@bobsmithy3103 This is exactly right, except for one quibble: you should think of dFdx and dFdy not as differences, but as derivatives. They are indeed implemented as differences (which means they are not magic, in that they don't give you an analytic derivative), but semantically they are derivatives. These may be the most useful operators that nobody (except those who came to OpenGL shaders from RenderMan) seems to know about, because they give you the information you need for shaders to antialias themselves.
9:37, I woulda put the x/y center at the top left of the normalised space, done normal caluations then just multiply the results against width and height normalised with the bigger have a smaller normalisation value, so 1 should be 1.0 and the bigger made to be smaller as a result of division, I think bigger divided by smaller would get the right value, this method ensures the dimensions are always as expected, as for x/y being in top left corner it makes it easier to multiply against position to get in right spot, only having to check if the position should be multiplied against positive or negative version of the axis
I think to get consistent smoothness with smoothstep the step size should depend on the resolution, as the goal is to for example stretch the step over 2 pixels (in which the smooth step size would be 2 divided by the total amount of pixels)
You should have used a linear interpolation for antialiasing instead of a smoothstep otherwise you get some weird two edged gamma "correction" I know as I compared both methods with Photoshop's antialiasing pixel by pixel. Additionally the fade variable needs to be calculated from texel size. When it's a constant you will get different smoothing for different circle sizes.
So you have to calculate, if a pixel is part of the circle and to what amount. That means, if a pixel is less than ~1 pixel away from the edge, then color it partially according to the amount of overlap. You could just use the floating point fraction from the distance (when it's
love this kind of video! can you make one about a way to fill a shape described by a series of point?
2 года назад
You could also use the derivative functions available in GLSL (such as fwidth) to make the smoothstep range one pixel in size, regardless of the scaling of the object or screen resolution. Would be pretty interesting to see that implemented!
I was wondering: regarding the thickness - wouldn’t you have to take into account the transformation applied (or the distance to the camera) within the shader function, so that a circle with a thin line (aka a donut of ‘tiny’ thickness) stays thin no matter the draw distance - or maybe even more relevant: the aliasing created by smoothstep() is working regardless of draw distance(? Proximity to the object ? Closeness to the camera?) . I guess I am throwing a lot different concepts together - my apologies for that - the last time I wrote code for an 3D engine is 15 years ago, I never worked with shaders, and I forgot about all the terminology and how different concepts play together.
@The Cherno Brilliant tutorial - I'm an audio DSP programmer and it's quite wild to experience the same sort of geometric thought process but in higher dimensions. (Audio is 2D, time and amplitude). @Daniels Liberating Structures-Kanal - I have the same question as you, but for ellipses with a high fade value. I wanted to ask specifically what local variable can we use to figure out the transform applied to the shader? If we had access to the "aspect ratio" of the ellipsoid, we'd be able to easily compensate for this stretched-fade / stretched-thickness effect, but being a complete newbie to openGL, I know that this problem would probably require a good day of plinking around and I'd really like to hear a professional chime in on this!
The correct approach to anti-alias an edge is to use the pixel width, which I believe you can get pretty easily in a shader with the derivative function on the UV (which just compares the passed value to what it is in neighboring pixels).
Pretty sure that will just come out in the wash when you project UV coordinates into world space. The rasterizer will calculate how the distance and perspective (applied in the vertex shader) affects each pixel. The fragment shader is only working with a sample point, usually the center of the pixel, but it could be multiple points if multisample shading is enabled. If you need a flat, constant width circle, you can either omit the transformation matrix from the pipeline, or you could use a "look at" function to render the quad and point it straight at the camera.
If we smoothstep this way, aren't we then losing the fade where the outer edge of the circle touches the four sides of the canvas? Could look a little chopped off if the fade is large. Might be worth subtracting the fade from the distance.
Thanks Cherno, interesting video, but what if I want to draw a circle in 3D space, viewed from any angle? Your method seems to only work if you are drawing a circle in 2D space, viewed from above and with the circle in the centre of the screen.
I ran into this EXACT issue the other day. For my 3D app, I wanted to add a circle around my mouse cursor similar to the paintbrush tool in photoshop, but I couldn't for the life of me figure out how to do it.
Thanks for the great video! The first time I implemented an SDF circle, it was a piece of cake until I got to the point where I needed to define a falloff for smoothstep(). Technically, the thickness of a circle outline should be oriented so that the middle of the thickness falls exactly on the radius of the circle, right? So half thickness on both sides of the radius edge. But this means the quad needs to be expanded (in clip space) by thickness*0.5 + falloff in every direction. Since my quads were sized in world space, trying to figure out how much to push them outward for this using a clip-space distance was not very much fun. I think I spent around 3 days on it.
To render a circle in a texture there are techniques like the Bresenham circle algorithm but it doesn't really apply to a shader as you treat the pixels independently. For antialiasing there a techniques like the Wu algorithm which is a simplified version of multi-sampling, but again i don't know if it would be really faster in a shader.
Looking at that code make me think of lights, perhaps there's a cheat method of lighting objects by simply going over the entire rendered buffer with similar math
Interesting topic. Since I would like to display points (millions of points from laser scanning) I'm wondering if I could display those points as small circles using shaders. To be fair, the points could also be represented as square, triangle etc with different size and colours.
Is this what games remasterers are doing for old games etc this kind of similar shading to make things more smooth? So potentially if I wanted to and could see game code I could smoothstep every step they have to remaster circles wheels etc myself?
If the triangle count is important, then just use a single, large enough triangle per circle instead of a quad. I can't recall how to calculate the exact size, however.
Cherno, you know how Unity optimizes sprites by "cutting off" the edges of the quad and tracing the outline? What if you do that here? Render a hollow octagon, or some n-gon, with a triangle strip topology, wide enough for the circle to lie within it. That would cut down on the number of fragments you have to calculate. I think there's a formula for the inner and outer radius of a regular polygon... somewhere lol
I bet if you covered c++ 3D games, like not writing a whole 3D game engine, but just coding a game like you would do with your old java series. That would be great.
How do you make it scaleable in GLSL? I have Matrices up and running, however it only scales the background of the "circle shader". Not the actual circle.
1m side square would produce a circle of 1m diameter. The 0.5m you're talking about is the radius. Just clarifying to make things easier to understand.
Greetings Kind Regards How the heck does your computer compute those shaded circles immediately upon change of your program or are you editing the video to make it appear so Thank You Kindly
So i watch all the videos i try to code at the same time with you do a different version of that code and when i think that i learn something i just don't I try to do some problems on code wars and even the easy ones are to hard for me any advace? Sorry for my english
The rasterizer in a GPU is kind of baked into the hardware, you can't really have a parametric function that chooses which pixels to sample. You could generate a point list of every pixel, perhaps with a compute shader. Not sure it would be any faster than this though. Listing every point is a lot of memory. You might get this one faster if you render over an actual mesh that doesn't process so many pixels.
@@DFPercush The GPU rasterizer can only rasterize points, lines, triangles and maybe rectangles. So this algorithm would need to be implemented as a compute shader. I don't understand your concern about memory. Whether you use the final image as a render attachment or storage texture shouldn't make much difference in terms of memory size.
@@_lod Yes, but the process shown in the video has a fair amount of overhead, because it has to run through the entire render pipeline, because the pixel shader is run for every sample.
@@ymi_yugy3133 Memory access time is what I'm thinking about, more so than size. Not sure what kind of cache a GPU has or what it has to share it with. Actually a tessellation or geometry shader might be better because it can just stuff vertices into the rasterizer pipeline and not have to allocate a buffer at all.
Google recommended me this video after watching Casey Muratori's video on rendering a circle. As if anything could top that. I mean I'm still going to watch this video and give it my engagement, obviously, but still.
Hey I have a question: What stops one from putting *everything* into one draw call? Like having a mega shader and then either: *A*. Pushing geometry on the CPU to a giant vertex buffer you push to the GPU each frame, or *B*. Using vertex and geometry shaders as well as some persistent buffer on the GPU and just having simple uniforms/imports you can modify for stuff to add/subtract/change
You absolutely can do extreme draw call batching (though typically not in the way you've described with pushing stuff to giant vertex buffer each frame) and a lot of games do it (not quite to the degree of everything in the same draw in any game I've seen, but it would be possible). Pushing your mesh data to the GPU each frame would be really slow because that can end up with an absolute ton of data you're trying to send over every frame. You should look into indirect draws though, they can handle this quite elegantly. Doom Eternal, for example, stores all its geometry data in a single large buffer, with even skinning being done in a compute shader and stored into the same buffer before rendering anything. This allows it to merge completely unrelated meshes into the same draw, and I believe it did something like 256 meshes per draw (I don't see why you couldn't do more if you wanted to, but there likely wouldn't be much of a performance increase at that point and it may need more data). Typically the buffer used for indirect draws would also be created on the GPU and not the CPU because it's much faster (at the very least after some coarse culling by the CPU). Doom Eternal also generates a big index buffer every frame on the GPU (so instances are unwound into real indices), which allows it to do per triangle culling. Having one big shader is a common thing used in many games, typically called an uber shader. There are examples on the internet where whole game worlds are rendered in one draw with indirect buffers, so really go research that.
@@Drillgon Wow, what a great response.. I do have one leftover question though: can you have like a persistent buffer on the GPU that survives multiple draw calls? That way you could just modify it instead of pushing every frame.
@@S41L0R Of course. In fact, you basically never want to be creating a new buffer every frame. Uploading data to the GPU that doesn't need to be updated should be avoided in most cases (some exceptions might be streaming assets into and out of memory, but that's not quite the same thing as uploading all the geometry every frame). Like I talked about before, you'll typically store meshes inside buffers on the gpu and not touch them unless the vertices need to be updated (which is the case if you're doing GPU skinning in a compute shader, but even then nothing is being uploaded because the GPU is just writing into it's own buffer). If you want to draw the mesh more than once, you instance it. You can make allocations into that buffer for completely dynamic meshes as well using any of the many allocation algorithms.
This is roughly what you are doing with ray tracing, as well! The entire geometry and material information is pushed into the GPU memory, then the shader can throw whatever rays it likes and put whatever output it likes out, all in one CPU side call. (You don't actually do this in one pass, in general, as you want to do clever things like aggregate lighting information over multiple frames and combine them, but that's the idea) RTX means you have explicit support, but since 2006 or so you could do basically ray tracing in pixel shaders: that's what parallax occlusion mapping and screen space reflections are, just in simplified cases that you can do quickly enough to be useful without acceleration.
Good as a joke :-) But for those who would try it "for real" - make sure that your engine/framework supports font rendering in the first place. Not sure that speed will be great tho (rendering a letter vs rendering the circle)
I haven't watched the video yet but my guess is for rendering a circle you want to just take a quad and render it as a circle with a shader taking the center of the quad as the center of the circle and comparing the distance of the UV from the center and if it's greater than the radius you render nothing and if it's less you render the circle
One thing that immediately came to mind when you started showing the fade effect, is what about anti-aliasing? It seem like the purpose of your fade is actually to avoid anti-aliasing while still making it look somewhat good. Why not apply proper anti-aliasing instead?
create video, another easy technic is to just draw a quad with a texture of a white circle on it. to color the circle just shade the texture and scale the quad to create an ellipse. the smooth shading isn't needed anymore if linear filtering is enabled. it is not possible to create donuts with this technic though.
Those are the times that I understand that working within games industry is a no-go for me =( My math skills are so bad that I don't even understand how I have a simple job.
