🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Is graphics programming still relevant in the game industry?

Started by
8 comments, last by Vilem Otte 6 years, 3 months ago

I've been doing game development for a few years now. I recently finished my degree in game development and programming, I'm a software developer full time and do my game dev stuff on the side. One thing that has kept me very curious ever since I took a graphics programming course in college, was whether or not it was really still relevant in the game industry. What I mean by this is to a team who is not going to build their own engine, a team who is going to use something like Unity or UE4 or any other number of game engines out there, is it really necessary for them to be able to program graphics on their own? I wonder the same about physics? It seems like these game engines do all the heavy lifting for us when it comes to graphics and physics. Obviously a basic understanding of them will greatly improve your ability to master what can be done with the engine, but to have several dedicated team members to graphics, is that necessary? Again, I understand that we need these people to build engines or if we want to modify the current physics or graphics of an engine. However I am talking about a team that is simply using a preexisting engine as is. Just curious as to opinions on this, especially from those who have worked on games professionally. Thanks!

Advertisement

At an, 'indie' level, probably not, but otherwise, yes. 

Unity is almost a framework for making engines, rather than a finished engine. There's a lot of room for customising the engine to fit your needs. They're actually making this easier in 2018 by making the core of the renderer even more scriptable.  UE4 is less flexible, but AAA teams would still have internal engine programmers tweaking their version of it!

No two games that I've worked on have ever used the exact same rendering code, even when using the same engine. This is especially true for console games where the hardware is so underpowered and the expectations are so high. 

Even when I was working at a small /sub-AAA console developer who pumped out ~$1M games annually, we had multiple graphics programmers on the team, plus a tech artist also doing graphics programming work sometimes :)

It's true that game engines handle most of the heavy lifting out there and aid you immensely as far as the graphics pipeline is concerned, but even if you do build a game on Unity or Unreal those usually don't get you all of the way there, especially when your game demands some more specialized advanced behaviors.

Say you want to implement a seeing through walls mechanic. What this guy did here is nothing short of impressive. His solution was built on Unity but required a lot of ability as far as the graphics are concerned. What if you wanted to implement a wall jumping mechanic? Or a gravity on the walls mechanic? There are tons of cool things you can do to your game that OOTB free game engines don't have implementations for. I'm working on a racing game where the track twists and corkscrews, and I needed a mechanic that would apply gravity to only the track. Unity's built in physics weren't really that useful  for me so I had to use some good ol' linear algebra to get things working right. </self-promotion>

The point is no matter how much heavy lifting these engines do, there's always a ton of ways to get creative on top of them, and it's going to making things way easier for you if you come in equipped with some of that mathematical/graphical knowledge.

1 hour ago, ethancodes said:

to a team who is not going to build their own engine, a team who is going to use something like Unity or UE4 or any other number of game engines out there, is it really necessary for them to be able to program graphics on their own?

The thing is a lot of big publishers still have dedicated teams working on in house engines that have their own rendering pipelines and physics engines. For example most Nintendo games are made on game engines that aren't publicly available. Id hasn't released their new engine they used to build Doom. A lot of these in house engines rely on various pieces of middleware from outside though, so they still need talented developers to string them together.

Thank you so much for the answers. This gives me a major insight into what I need to continue learning. I've been studying linear algebra and just math in general for 3D graphics and physics, but I wasn't sure if it was really worth it. Now I know it is and will continue to learn it! Thanks again!

Graphic coders are always extremely in demand! I've been working in the game industry for the past 20 years and that hasn't declined one bit, quite the opposite. We currently work with Unreal engine and we always need graphical programmers. Even with Unreal being so feature rich and quite accomplished engine. As mentioned above just about every team (Character art, VFX, Environment, Design...) will need graphical coders through the project as well as dedicated engine/physic coders to keep extending or customising the engine with particular needs the project may have.  If you love maths, 3d graphics and physics you'll have plenty opportunities in the industry as a graphical coder. :)

(Extra perked game development teams usually worship their graphical coders.)

 

I'm fascinated with the math behind graphics and physics programming. But I'm not very experience with how to implement it. I find it difficult for low experience programmers like myself to find ways to implement this kind of stuff. Do you have any advice for me on where to start actually doing some of this, instead of just reading about it. lol. 

Scribbles of a madman. My apologies for a very stream of conscious and none concise way of writing. I likely deserve capital punishment for all my grammatical atrocities as well. Keep in mind I'm not a graphical coder, I have an undying interest in the field and worked with many graphical coders, had plenty of dialogue with these cretins and dabbled over the years in the subject. I did however observe closely great fantastic graphic coders and their highly driven nature and interests.

Although it all starts with the question: How do I...
This is agnostic to any field, doesn't matter what you want to become or set out todo. However It's all about asking the better questions, more specific, narrowing down the question, getting better at asking the right question, be inquisitive, read, learn and be driven and disciplined to keep progressing and learning. 

Any general none specific questions these days are better asked to Google.
You can literally type in Google How to be a graphical coder and you'll find tons of quality information already written by experienced graphical coders. Which will get you on your way. Read them all!

Then instead of asking how I become a graphical coder. Ask yourself what do you want to learn? What specific interests you and search for that. If you don't know than search for all of them and on the way find out what your specific interests are.
Get 3d engines, unreal, unity, search for demo scene and learn how to make your own demo's, go on shadertoy create your own, look and join Github to find interesting Nvidia/Unreal or whatever realtime 3D projects and branches that interests you, get and look at the source, compile run them, get used to the libraries, and what not. Get graphical debuggers, learn which ones are available. Learn OpenGl and DirectX, go through examples and courses. Go through the beginner classics like lazyFood (http://lazyfoo.net/tutorials/SDL/index.php). Look at Libcinder (https://libcinder.org/docs/index.html)
There are plenty shared source out there, and just getting it, reading, compiling, looking at it will get you on the way. 

If it's physics, think what fields of physics interests you, fluids? Destruction? Search for that. Look at the latest and newest realtime implementations. Search and look for whitepapers, GDC, Nividia Blast,  

Just as with anything, it's practice practice and it starts with looking for that you want to practice in and practising. 

 One thing all great graphical coders I worked with had in common, was that they are all very (VERY) driven to learn and read.  And that it required many many moons to acquire and master the knowledge. (These are actually the very wording one particular talented graphical coder once said when we voiced how much dedication goes into Graphical coding. Literally many many moons...as in years to decades)

Graphical coding is an enormous vast ocean, so its easy to be overwhelmed, and drown into it. Or even not know where to start. But there is no shortcut, it is literally dive in and keep swimming. Keep reading, keep learning, keep finding what you are interested in and search for that.

Give yourself direction based on what interests you, not just graphical coding, but what exactly in graphical coding you like the most and start there, if you don't know, search for it all and immerse, acquire it it, read it, own it! You should try to learn very quickly to be your own compass. Only you can learn what direction interests you the most and where you want to take it. Nobody can define your core interests. And once you define your interests its all about searching for it through google and doing it, practising it. Finding the forums of the topics your going to code or practice in. 

Couple things that might help organising wading through the madness of vast amounts of available information. Is develop a good  clear habit of bookmarking. Maybe get a trello account and create a board (or many boards) to help you navigate, keep track of everything you learn, it will also help focus on topics that interest you more and if jump back in if you left a topic for a couple days to a week because you where busy with other topics. It will also help collecting the hundreds of different websites that you need.

In the end it's all about searching online forums, courses, websites and keep reading and practising. And at many times you might feel you don't progress, and you don't know how, that comes with the friction nature of learning. But as long as you do, you will progress. And find out how to actually do it.

Check out github for opensource projects.

If you already read a lot of papers,yet never write any code.

Just search those opensource engine,practice projects to start.

Can save you a lot of time to build from the ground.

Fork and add your own feature.

And www.shadertoy.com

a lot of interesting and cool examples.

As I have experience in more - Unity (and other game engines) and custom game engines - I can clearly state that any non-custom engine is restrictive at some point. You can clearly figure it out by attempting to add some specific feature in Unity (Such examples being as small as adding Voxel Global Illumination - and I know there is an implementation around, but it is extremely limited ... compared to custom engine implementation). Yes there is a way to work around, but it often takes multiple headaches with Unity ... or as big as large terrain rendering).

In the end it all gets down to:

  • Do you have resources to produce and maintain custom game engine?
    This often means spending hours and hours weekly on engine. Including (for some people) very annoying parts where you work with internals - which isn't really visually rewarding in any way.
  • What advantages will custom game engine give to you?
    This is not necessarily saving money (because it will most likely get far more expensive than using already built engine). But do you require specific features and high performance? Then custom engine may be something for you.
  • What are your time options?
    If you're in a hurry (doing a game jam, or such), custom engine can provide large disadvantages due to missing features. While Unity or others might already have those ready made. Simply because they are far bigger projects.
     

An example can be F.e. this:

This is my engine in action - PBR rendering, Voxel Global Illumination re-calculated every frame (therefore noise), MSAA and deferred shading (multiple lights), Virtual shadow mapping, Physics, Dynamic cone-traced reflections, Instancing, etc. etc. (A very long and exhausting list of features). All this is recorded in editor (UI is fairly simple through ImGui but it is enough for the purpose I need). Average framerate is over 60 fps (with recording on ... and 4x MSAA for every single buffer up to resolve AFTER tone mapping - hence huge bandwidth usage).

Average CPU usage with the physics is well under 5% (whole engine is multi-threaded, and uses all 8 cores of Ryzen CPU on which I've ran this).

So why am I describing all this?

Compare with this - https://ldjam.com/events/ludum-dare/38/run-u-fool - and I recommend, try both - WebGL and Desktop builds. Shattering objects can't be activated at once (due to performance reasons), there is far less graphics effects and far less actual logic for CPU (it runs as a runtime, not as an editor). It is not just the performance difference, but also GI and other features which are hard (if not impossible) to achieve with Unity. Yet can be well optimized in your custom game engine.

 

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

This topic is closed to new replies.

Advertisement