11 ms·
I would suggest that beginners not lead with "which tools should I capitalize on" and instead, take a step back and ask "what do I want to make"? Don't lose foc
by stemlord 3y ago
I would suggest that beginners not lead with "which tools should I capitalize on" and instead, take a step back and ask "what do I want to make"? Don't lose focus on the final output as you make your first steps. In the world of computer graphics today there are so many tools that abstract away various steps in the process of drawing pixels to the screen that you could very easily waste too much time suffering with low level code up-front and then later realize that the niche field in the wide array of industries that utilize graphics programming that you want to pursue actually only hires people who use Unity, TouchDesigner, threejs, and after effects and don't actually write a lick of C++ unless push comes to shove, and even then they might just contract an outside engineer for it.
Not to say that learning how things work on the ground level isn't immeasureably valuable, but I think trying to do that first is the slow approach. Learning is accelerated when 1) you enter the industry (so you should prioritize output up-front and let the deeper learning happen when you're earning a paycheck for it) and 2) you get a better conceptual understanding of what's happening under the hood offered by tools of abstraction like a game engine or visual programming paradigm.
This comes from someone who spent many years trying to learn cpp and opengl the hard way only to endure a long battle against an internal sunk cost fallacy I've harbored that kept me from taking the no-code approach. Don't waste your time taking this path if it doesn't help you make what you actually want to be making at the end of the day.
- captainkrtek 3y agoThis is great advice. I think it’s a common trap when I see questions like “what language should I learn/what language is the best”, which skip the point of “what would you like to build”. The tools change with time, and the best engineers in my experience generally know how to use a variety of tools with varying degrees of skill rather than be super deep in a single one.
- johnnyanmac 3y agoI don't think it's necessarily a trap. People asking this question more often have the underlying question of "how do I get a job doing X?" so they are asking "what do job posts expect out of a graphics programmer?". It's more fickle, becuase you can definitely build amazing stuff with WebGPU/WebGL and JS. But it might not get you past the dreaded HR filter.
- captainkrtek 3y agoSure, trap probably wasn’t the best word choice.
- ryandrake 3y agoListen to this guy, great advice. Early in my career, I set out to become an "OpenGL expert" and I'd say I mostly got there. I mean I'm no Mark Kilgard and haven't written any textbooks, but I dove super deep into the technology, and gained at least a decade of experience working on all levels of the API from the driver level to conformance tests and performance tuning, up the stack to game and application code, and across each major desktop and mobile platform. Where did it get me? Not very far, really. First of all, almost nobody cares about OpenGL anymore--it's kind of dead with the two major OS vendors finally abandoning it. Go to any "HN Who's Hiring" and text search for OpenGL. Sure, I could have gone and re-skilled and learned another similar graphics API, but the second problem is nobody really needs people who write low-level Direct3D or Vulkan or Metal anymore because that's all abstracted for you by engines. And there are max 5 or 6 companies in the world that even have the need for people who can do low-level graphics drivers. It's a career-limiting niche. The smaller the piece of the machine you focus on, the more of a world-class expert you need to become in order to make it your whole career. So, unless your plan includes becoming the next John Carmack or something, I'd recommend going broad rather than deep.
- raincole 3y agoBut without people like you (who understands the low-level graphics programming), the development of engine will completely stagnate.
- BobbyJo 3y ago[flagged]
- thejazzman 3y agoyikes.
- nahumfarchi 3y agoThat escalated quickly
- ywain 3y ago
- TheRoque 3y agoWell, as someone looking to get into this field, I kind of disagree. A lot (if not all) job postings about graphics programming require you to know C++ beforehand. Sure, you can have another role, like gameplay programmer, and slowly work your way in graphics, and it's probably easier to do so, but in fine, for the graphics programmer role, C++ is required. What you are describing is more about someone who wants to be productive with graphical stuff fast, but it's not graphics programming.
- pjmlp 3y agoFirst learn the foundations, then the language. When I started, graphics programming was all about Assembly. Then it was about Object Pascal and C, then it was about C++, now it also requires C#. And who knows, maybe in 20 years, one of the C++ wannabe replacements manages to also have a spot, or some AI driven thingie. Those will solid foundations in graphics programming algorithms, will manage regardless of the language.
- dahart 3y ago> now it also requires C#. For Unity games? What else? Just curious. I’ve been doing graphics programming for decades, and C# has never been part of it, and still isn’t on my radar.
- pjmlp 3y agoYes, plenty of Unity shops, and most of the companies doing VR/AR are using Unity. Not only Unity, Capcom has their own C# toolchain. One example of a Capcom game that makes use of it is Devil May Cry for PlayStation 5. Unreal build system is based in C#, although here is a minor role, and naturally debatable.
- meheleventyone 3y agoThere’s two or three strands of graphics programming though: Plumbing - Delivering data efficiently from the game engine to the GPU often in a platform agnostic way with efficient implementations underneath. Art Pipeline - Delivering data efficiently from the artist tools to the game engine. GPU Programming - Creating visual effects, shaders, compute shaders and tools around these to empower artists. All of these use multiple languages, sure C++ is a common one and good to know (likewise as a gameplay programmer) but the bigger percentage of what you need to know as a graphics programmer isn’t how to write C++ but the concepts you’re trying to implement with it. There’s also R&D but it’s a much smaller part of things.
- ronhews 3y agoI agree with your suggestion to focus on what you want to create rather than immediately diving into specific tools. It's important to keep sight of your end goal and prioritize output. While learning the fundamentals and low-level code can be valuable, it may not always be the most efficient approach. Tools that abstract away certain complexities can provide a better conceptual understanding and accelerate the learning process. Ultimately, it's about finding the balance between gaining knowledge and creating what you're passionate about.
- nullptr_deref 3y agoThis is hands down the reality and the best advice out there. No one cares if you are able to do vulkan for 8 years EXCEPT for research labs. And getting there requires that - you either have a PhD or the exact experience (threeJS, unity etc) as above because that will help you set foot on industry effectively allowing you to work on higher abstraction and slowly/rapidly decent into low level code.
- johnnyanmac 3y ago>you either have a PhD or the exact experience (threeJS, unity etc) as above because that will help you set foot on industry PhD seems extremely overkill unless you know the exact kind of graphics programming subniche you want to work in and are deadset finding the half dozen labs focusing on that. I don't think you need that kind of specialization to get a gig in games or VFX if your goal is indutry. Exact experience is exactly why people ask about what to learn. If you know most people use UE5 it might make more sense to focus on the high level stuff to appeal to studios than to dig into Vulkan for years.
- beAbU 3y agoThis is the classic trap that new developers step in all the time. It's not just associated with graphics programming. Youtube is full of beginner programming videos that take the developer through a journey of learning a stack of technologies in stead of focusing on something interesting to build. You end up with a lot of cargo-culting, and these massively complex Ruby Goldberg contraptions to render some text on a web-page. All in the name of padding out that CV. When I was in university I dabbled with some graphics programming for a semester, and I found it was sufficiently complex that the only reasonable answer to "what do I want to make" was "render a green triangle on a black background". Going from there to square, to cube, to sphere, to animated sphere, to bouncing ball, is a logical progression and it helps you stay focussed on the prize. So don't also make the mistake of answering the above question with "first person shooter with ray-traced lighting and subsurface scattering". I can promise you the first iteration of a bouncing ball will be truly horrible code. But that's fine. Over time you'll figure out how to optimise and improve things. And let me tell you, there's nothing as invigorating as discovering a design pattern by yourself: reading a book on a new topic and going "hey I'm already doing that!"
- dgb23 3y agoTangent: And if you then tell about the pattern/technique/architecture etc. to someone who’s been around for a while: „Well, we already did that in the 80‘s, it was called Foobar. We just had to do it barefeet in the snow with our hands tied to the back.“
- DanielHB 3y agoMuch like sorting algorithms I still think there is some value of teaching this kind of low-level programming in college. You gain a lot of theoretical knowledge as well as a lot of heavy complex algorithm training even if you never end up doing that kind of work in a real job. With graphics it also gives you a lot of applied _math_ experience, there are a TON of fields that are desperate for people who can do math. Just my last job (software for CNC machines) we needed people who could do program the math necessary to program a drill to but a certain shape into a metal block and it was really hard to find these people. Yet, for example, cloud devops engineers, although expensive, were readily available