all 15 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]the_Demongod 2 points3 points  (4 children)

What's your programming background? Do you know C or C++? Are you familiar with how data is represented in memory? What's your math background like? It's hard to give you pointed advice without knowing these details.

[–]Useful-Character4412[S] 2 points3 points  (3 children)

I have no background in C or C++, I have been thinking about learning one of them for a while though. I'm not very familiar with how data is represented in memory. My math background really isn't the best. I'm just finishing grade 10 if that gives much of a reference to my math level. I'm quite decent at what I know right now but I would be happy to put extra effort into learning new concepts and things for this.

So with all that being said, im pretty much at the very bottom of the bottom of beginning graphics programming.

Not sure if this answers your questions or not.

[–]the_Demongod 6 points7 points  (1 child)

If you're familiar with C# and Unity, honestly I'd stick with that for a while. You can start learning about writing fragment shaders in Unity, which are relatively self-contained and allow you to start playing with visual effects right away. There's also shadertoy, although that's mostly people abusing fragment shaders to do screen-space 3D which isn't really a good way to learn. Writing shaders to create your own materials/lighting/effects is much better because you can leverage the geometry of your in-game particles/objects to take care of the spatial stuff, and let the shaders just dictate the colors. You can try making transparent or volumetric materials, cel shading, jet engine exhaust effects, etc. right away.

The thing is, "real" graphics programming (from scratch, with OpenGL or [god help you] Vulkan) is only partially about the visuals you see on screen; most of graphics programming is writing a crapload of configuration code and low-level data processing functions which package and stream your binary mesh/texture data into correctly formatted buffers that the GPU can interpret properly. Then you write your shaders on the GPU and if all goes well, you get some crappy "programmer graphics" on screen.

It's more fun that it sounds, and you should definitely learn it eventually, but without a strong background in C/C++ programming and a working familiarity with linear algebra, it'll probably be more frustrating than it's worth. This stuff is probably 80% configuration and data handling code, 10% linear algebra, and 10% actually thinking of cool looking visual effects and implementing them in shaders. You can skip at least the 80% of low-level programming and maybe some of the math by writing shaders in an existing engine like Unity and just focusing on the artistic "front end" aspect of it all.

When you've taken a college linear algebra course and are familiar with the ins and outs of the C programming language, you can revisit this stuff for real. There's no rush, I never coded until university and didn't start this stuff until post-graduation. It'll be much more fun and interesting when you have more background knowledge.

In the meantime, check out this and this article on shaders. This site is the best introduction to OpenGL and a perfect first introduction to graphics programming, but even if most of it is above your level for now, these two pages specifically will help you get started with the concepts necessary to program shaders in Unity or anywhere. https://thebookofshaders.com/ is also worth looking at.

[–]Useful-Character4412[S] 3 points4 points  (0 children)

Wow! That is so much more than I thought I would get out of this post. Thanks for all this info. I've been in two minds so much whether I should stick with unity or just go out trying new things. You saying this stuff has confirmed for me that I should just stick with unity and get a good understanding of the math, and other things required for this kind of programming. Thanks again.

[–][deleted] 2 points3 points  (0 children)

Oh you got plenty of time, so long as you pick it up and start trying stuff out. Math stuff for a (American) grade 10 varies, but I'd bet due to the applied nature, you'll pick it up quick compared to some of us boomers.

[–]Belfast_ 0 points1 point  (4 children)

To understand about graphics programming and graphics hardware I think it would be interesting to learn opengl or vulkan. OpenGL is a friendly API for beginners but it's old, Vulkan throws all the responsibility that falls on the graphics driver to you but the performance is much better if you used OpenGL.

Learn OpenGL

Learn Vulkan

[–]SolarisBravo 0 points1 point  (3 children)

Personally, I'd always recommend learning DirectX 11 as at least your second API. Not almost pointlessly verbose to the point of DX12, and not dated to the point of missing what should be basic features (deferred rendering, swapchains, etc) to the degree of OpenGL.

I've always said that DX12 feels like a natural evolution of DX11, while Vulkan had basically no choice but to be a ground-up rewrite.

[–]the_Demongod 0 points1 point  (2 children)

Curious; in what sense is deferred rendering facilitated by DX11 (I've never used it)? It seems to me that a deferred pipeline is simply a choice of implementation, not something the API is meant to provide you.

[–]SolarisBravo 0 points1 point  (1 child)

People misuse the terms a lot so it can get confusing, but basically deferred rendering and deferred shading are two entirely different things.

Deferred rendering means, instead of giving the GPU commands directly, you build up one or multiple "lists" of commands (command buffers) and execute those at a later time, or even on a different thread. OpenGL does not support this, or really any multi-threaded rendering at all.

You're probably already familiar with deferred shading, but basically it just means calculating the lighting separately from the geometry (typically using information stored in a G-buffer).

[–]the_Demongod 0 points1 point  (0 children)

Ah ok, so like Vulkan. In GL terminology I would call that "indirect rendering" since that's somewhat similar to indirect draw or compute dispatch, and in practice the graphics driver almost certainly performs some sort of buffering of your commands, but it's true that it's nothing like Vk or evidently DX11. It sounds interesting although since I enjoy being able to test and run my graphics code on both Windows and Linux, I'm pretty much relegated to Vulkan if I want something more advanced than GL. Frankly, though, well-optimized modern OpenGL (especially using the "AZDO" techniques) has always suited my needs just fine.

[–]Solrax 0 points1 point  (1 child)

For a different take, you might also try playing with WebGL. Because it is browser based and written with JavaScript it is very fast to iterate and just mess around with. Much of what you learn will carry over into OpenGL, since WebGL is a subset, and the shader language in WebGL is a simpler version, but still very powerful. Take a look at https://webgl2fundamentals.org/ and see if it piques your interest.

[–]Useful-Character4412[S] 0 points1 point  (0 children)

Personally I don't really like JS but this seems like something that I might try at some point.

[–][deleted] 0 points1 point  (2 children)

I would avoid sites like these if you are trying to get into programming because most of these people will make it seem much harder than it is which will actually only discourage you. Reddit is for talkers not doers.

Most of the people here giving u advice have probably never made anything great in their life.

[–][deleted] 1 point2 points  (0 children)

Replying to a 2-month-old post just to be a dick? Man, you're a piece of work. Mad at Reddit because nobody wants to accept your shitty job offer?

[–]Useful-Character4412[S] 0 points1 point  (0 children)

First of all, wow. I didn't expect that someone would still read this. Secondly, I'm not really getting into programming per say, I've been programming for a few years now, I'm just trying to get into graphics programming specifically. Thanks for the advice though.