[HN Gopher] Graphics Programming Weekly
___________________________________________________________________
Graphics Programming Weekly
Author : E-Reverance
Score : 81 points
Date : 2021-02-14 18:38 UTC (4 hours ago)
(HTM) web link (www.jendrikillner.com)
(TXT) w3m dump (www.jendrikillner.com)
| 0-_-0 wrote:
| RSS feed of the newsletter:
|
| https://www.jendrikillner.com/tags/weekly/index.xml
| OskarS wrote:
| I love this little newsletter! Always a pleasure to see it arrive
| in my inbox, usually has at least one or two really interesting
| articles in it. Highly recommended!
| jak6jak wrote:
| I've always wanted to get into graphical programming but I always
| get hung up on creating anything. Shaders feel like black magic
| to me. And the tutorials are spread across many different
| technologies and techniques that it's hard to determine where you
| should start.
| Arelius wrote:
| I mean they are a bit. They are programs that fit pretty
| arbitrarily into other parts of the rendering pipeline. I
| recommend starting with Compute Shaders as those end up being
| just a big parallel map on your dispatch size. A lot less
| pipeline to understand.
|
| The other key thing to understand, is that a GPU is across a
| network (PCI-X network generally) So when you call dispatch,
| your generally sending a message (encoding a command in a
| command buffer) to do the work later on on a different device.
| Arelius wrote:
| > cmdList->Dispatch(dispatchSize/64, 1, 1);
|
| > [numthreads(64, 1, 1)] > void main(uint3 threadIdx :
| SV_DispatchThreadID) {
|
| the dispatch size (x, y, and z) are multiplied by the
| numthreads components (Some compiler SIMD stuff requires
| this) And that sum total threads (x * y * z) are launched.
| the index of the thread this particular invocation is
| launched on is left in threadIdx, you can then use that index
| to read and write from other buffers.
|
| This is HLSL, but the same generally applies to most APIs.
| Then more of this just becomes implicit and behind the scenes
| for shaders dispatched in other contexts, since more is known
| implicitly about the context, and more is done by other units
| of the hardware.
| soylentgraham wrote:
| What do you want to make!
|
| Starting with a software renderer is nuts.
|
| Start with unity, make an unlit shader, start doing basic
| effects (in colours, then using texture samples) using uv
| coordinates. (In frag, ignore vertexes to start with). Just
| remember youre just colouring a pixel, on a bit of a surface.
| d26900 wrote:
| > Starting with a software renderer is nuts.
|
| No, not really. You can write a simplistic ray tracer and
| rasterizer in about 10 - 50 lines tops:
|
| https://github.com/d26900/JamaisVu/blob/main/tests.c
|
| Lines 66 - 91.
|
| The result/screenshot: https://github.com/d26900/JamaisVu
|
| If this is "nuts", then so be it. Let me be nuts. :P
| qbasic_forever wrote:
| Build a raytracer from scratch. It's a couple hundred lines of
| very straightforward C code, or much, much less with a higher
| level language. You will learn _a ton_ about the rendering
| pipeline, transformations, lighting, shading surfaces, etc. It
| is super satisfying the very first time you run and finally get
| some colorful shaded spheres floating in space--you'll remember
| that moment for a long time. This is just one of many resources
| to help get started with a raytracer:
| https://www.realtimerendering.com/raytracing/Ray%20Tracing%2...
| d26900 wrote:
| Peter Shirley's one is nice too!
|
| But he has 2 more:
|
| https://gamephysicsweekend.github.io/
|
| And you can do a very simple one in much less than 30 lines
| in C. ;)
|
| Edit: Oops, it was the wrong one... This is the right one:
|
| https://raytracing.github.io/
|
| Sorry!
| ggambetta wrote:
| May I suggest my book? The full contents are online:
| https://gabrielgambetta.com/computer-graphics-from-scratch/
| jak6jak wrote:
| I saw that book but was confused on the way to use it. Are
| you supposed to follow along and turn the pseudo code into a
| real implementation? Or is meant to be Passively read while
| perhaps taking notes?
| ggambetta wrote:
| I guess that's up to you. Both work, although it's probably
| best if you follow along and implement the raytracer and
| the rasterizer as you go.
| kemiller2002 wrote:
| And here I was hoping this was going to be a worthwhile link
| to check....except i've already bought that one :p.
|
| In all seriousness. It sounds like a cool book. Can't wait
| til it arrives. Thanks for writing it!
| d26900 wrote:
| It's a great book! Thank you for your effort and for making
| it accessible to people for free!!!
|
| Edit: (If I wouldn't be so poor, I would donate to your cause
| as well.)
| d26900 wrote:
| I would start with fundamental rendering algorithms first
| before anything.
|
| - Write a software rasterizer
|
| - Write a software ray tracer
|
| You can do all that without exiting a programming language's
| standard library.
|
| I wrote a simple ray tracer (primary rays only) in vanilla C89
| in about 30 lines (if you don't count the PPM image library
| that I made):
|
| https://github.com/d26900/JamaisVu/blob/main/tests.c
|
| Lines 66 - 91.
|
| Screenshot:
| https://raw.githubusercontent.com/d26900/JamaisVu/main/scree...
|
| Here are great resources:
|
| - https://www.scratchapixel.com/
|
| - https://www.gabrielgambetta.com/computer-graphics-from-
| scrat...
|
| - https://erkaman.github.io/posts/junior_graphics_programmer_i.
| ..?
|
| - http://immersivemath.com/ila/index.html
| theschwa wrote:
| Graphical programming is a blast. I can totally see how it
| feels overwhelming, especially with a lot of ways to do the
| same thing. I will say though that once you get started a lot
| of the knowledge is transferable to different technologies and
| methods. I tend to recommend that people start with The Book of
| Shaders [0].
|
| What kinds of things would you ultimately like to make?
|
| [0] - https://thebookofshaders.com/
| jak6jak wrote:
| I tried the book of shaders but I think I got stuck when it
| got into the algorithmic drawing. I kept on getting confused
| on each individual line and how it fit into creating the
| whole picture especially when smoothstep() is involved. As
| for what I want to make, nothing in particular right now my
| end goal is perhaps to get a job as a graphical programmer
| somewhere.
| theschwa wrote:
| Yeah, that makes sense. There's some mental gymnastics
| involved in writing shaders since you're writing the code
| from the perspective of an individual pixel. As opposed to
| other methods like using Processing or the HTML canvas
| where you can just say "draw a square from here to here and
| make the lines this thick". When writing a shader, I have
| think instead "Ok, if I want a line here, and I was a pixel
| on that line, what would I need to know to determine my
| color".
|
| If you're finding that to be the obstacle with shaders, it
| may be helpful to start with just learning a library like
| Processing, or general graphics library in whatever
| programming language you're comfortable with, and then come
| back to shaders. It will still take changing how you think
| about things, but then you'll have some solid foundation.
|
| Personally, I've found it the most helpful to have some
| kind of goal in mind. Some kind of image or style that I
| want to make, then figure out what techniques I need to
| learn to get there. Starting from the technical side can
| work, but then it can be easier to loose interest when
| things get challenging. When I start with an artistic
| vision, then I often find myself over my head in the
| technical things I need to learn, but I feel motivated to
| push through that to get to the end goal.
| tpmx wrote:
| A very general piece of advice:
|
| Try to find a small and unusually talented team doing what you
| want to learn, and get hired by them. There is no substitute to
| learning from smart/experienced people.
|
| (This is after learning the basics + the intermediate stuff.)
___________________________________________________________________
(page generated 2021-02-14 23:00 UTC)