Designing a graphics programming portfolio

Started by
7 comments, last by MJP 9 years, 1 month ago

So as a personal side project I want create a bunch of graphics demos to portfolio-ize my graphics knowledge. I wanted some suggestions in terms of what to put in it. I want have three categories of demos:

Basic - What you expect any first year prrofessional game graphics programmer to be able to do.

Intermediate - If you were to take all the professional graphics programmers in the industry and sort them by ability, everybody on the good half of the bell curve would be able to do these demos.

Advanced - What you'd expect a senior level graphics programmer be able to do.

This is what I have planned for basic demos:

-Mesh Loading

-Gouraud Shading

-Phong Shading

-Texture Mapping

-MultiTexturing

-Normal Mapping

-Cube Mapping

-Cell Shading

-Shadow Mapping

-Image Post Processing

-HDR

-Deferred shading

-Anti Aliasing

-Skeletal Animation

Is there any other basic demos I should add in?

I plan on getting through the basic graphics demos and then do some AI demos as part of another project. I'll probably revist the graphics project when DX12/GLNext roll around and then add some intermediate/advanced demos to the mix. I could also use suggestions for intermediate/advanced demos.

Learn to make games with my SDL 2 Tutorials

Advertisement

If you don't have any of the things on your list already, this could take a while to get to.

I wouldn't really count these as really anything. They are basics of the steps needed to learn, but those alone I wouldn't consider as anything on a resume. It shouldn't take you very long to get these things done. They are more complicated if you are writing all of the mesh loading and extracting tangent map data, and splitting vertices etc.

-Mesh Loading

-Gouraud Shading

-Phong Shading

-Texture Mapping

-MultiTexturing

-Normal Mapping

-Cube Mapping

The thing with graphics programming or any game programming on a resume is more about presenting a fully workable system. If you want to do something with graphics, animate a bunch of characters in a busy city and have them with an avoidance system and make some shaders on some cars etc. Seeing something like this as opposed to a wall with tessellation applied or a demo of a single character animated in your code, is a big difference. Plan to build something that has a purpose. Find some free models, like from turbosquid or elsewhere and come up with an idea for a scene. If you have ever seen the nvidia demos when they release new graphics cards, they have small scenes with characters animated and some other background stuff going on.

NBA2K, Madden, Maneater, Killing Floor, Sims http://www.pawlowskipinball.com/pinballeternal

As a portfolio type piece, I wouldn't even bother putting out anything that doesn't include full per pixel lightmapping with a basic tangent space bump map implementation. As adam said above, most of that list is just a waste of time. Post proc, HDR, deferred shading, forward+, PBR - these are things that make for portfolio items. I wouldn't count skeletal either unless you do something above and beyond a simple model playing simple full body animations.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.


The thing with graphics programming or any game programming on a resume is more about presenting a fully workable system. If you want to do something with graphics, animate a bunch of characters in a busy city and have them with an avoidance system and make some shaders on some cars etc. Seeing something like this as opposed to a wall with tessellation applied or a demo of a single character animated in your code, is a big difference. Plan to build something that has a purpose. Find some free models, like from turbosquid or elsewhere and come up with an idea for a scene. If you have ever seen the nvidia demos when they release new graphics cards, they have small scenes with characters animated and some other background stuff going on.

I completely agree with this. Implementing the individual items you mentioned in your OP is something you could easily achieve by just following a bunch of tutorials, which is something any relatively skilled programmer can do. If you want a demo which stands out you'll have to show that you actually grasp the concepts you mentioned and that you know how to use or modify them to achieve a certain desired result.

At my current position I mostly do rendering, and it never comes down to building just these simple techniques which could be found in tutorials, if that were the case there'd be no need for dedicated rendering engineers at all. Instead it comes down to being able to achieve a certain visual style, system or technique within the constraints set up by the project you're working on (be it performance, style, target audience, etc.). Like any software engineering position it comes down to problem solving and knowing your toolbox inside out so you can solve your particular problem in the best way possible.

So yeah, learn the techniques you mentioned and build something with them which achieves a certain goal you've set for yourself. That way you can show your potential future employers that you have the skills necessary to solve problems instead of just being able to reiterate something you memorized from a tutorial.

I gets all your texture budgets!

Ok one last thing I forgot to mention:

Yes obviously nobody is going to be impressed by a Goraud shading demo in 2015, but this project has a second purpose. Metal, Mantle, DX12, GLnext, etc are The Next Big Thing™ and I wanted to get some practice in with them. A texture mapping demo won't light anybody's world on fire, but it serves as a good unit test.

The purpose of the Basic set of demos is more to serve as unit tests for porting the render pipeline to a new API. The Intermediate and Advanced are for future interviews. Also the basic demos could be used as basis for something more advanced IE skeletal animation -> skeletal animation with IK -> skeletal animation with IK/Cloth.

So yeah if the list of Basic demos look minimal, they're supposed to be. I just wanted to make a list of the bare minimum things to have so I could come back and expand upon them later.

Learn to make games with my SDL 2 Tutorials

I think its all fine and good to make those demos, however they really shouldnt be highlighted on a portfolio (which is what the thread/replies were about). You shouldnt be showcasing what is expected for the position you are gearing your portfolio toward, you should be going far beyond that if you want to be competitive. As has been mentioned, showing more advanced demos works as showing you know about the basic stuff (which nobody really cares about).

If you were applying for a call center job, you wouldnt put "I know how to form words with my mouth" on your resume. So why would you put "I know how to load a 3d mesh from a file" for a rendering position.

You want to show the most amount of knowledge in the least amount of time possible, so skip anything that can be easily inferred. (And make sure it looks damn sexy/impressive to get by any non-technical HR).


Metal, Mantle, DX12, GLnext, etc are The Next Big Thing™ and I wanted to get some practice in with them. A texture mapping demo won't light anybody's world on fire, but it serves as a good unit test.

Alright, fair enough, but just fyi I can tell you that you won't get much experience with the new APIs by doing these small demos though. I have hands-on experience with more than one of those APIs you listed here, and while I can't go into specifics I can tell you that doing these very basic things will barely require you to learn any new concepts at all within these new frameworks.

The whole concept of shading or texture mapping are not getting changed or replaced. As a matter of fact, you could probably even use your existing DX11 shaders on a couple of these new platforms without having to make any changes to them at all. These new APIs are mostly about the bigger picture and the optimizations which can be made by reducing driver overhead and state changes and by giving the developer more control over his/her application. The only way to really master those concepts is by having a more fleshed out demo in which you can actually play around with and see the effects of these changes.

I gets all your texture budgets!

My advice would be to go for less features/ quantity, and really exploit the ones you pick.

Crealysm game & engine development: http://www.crealysm.com

Looking for a passionate, disciplined and structured producer? PM me

I agree with others that for an awesome portfolio, you'll really want some kind of game or "real" project that makes uses of some cool rendering techniques. Keeping up on the latest research and techniques from other games is fantastic, and definitely vital for any graphics programmer. But the process of deciding which techniques work best within the specific requirements of a game or project and then implementing it in a way that it's usable for content authoring requires a completely different set of equally-vital skills. When I was learning, just making a simple 3D game was really illuminating for me since I got some experience with thinking about how tech serves the needs of a game, and how to make different systems work together.

This topic is closed to new replies.

Advertisement