Becoming a technical artist with no art background

#1

Hi everyone,

I’ve been googling and looking around on the threads here for advice on becoming a technical artist. I have compiled somewhat of a roadmap, however most of the threads here asking come from an perspective of an artist. As for my background, I am currently a junior (heading into senior after summer) at an university studying Computer Science. However due to a combination of my previous projects, my current hobby game dev with an artist friend, and my short experience as a music major at a conservatory; I think that I am growing more and more interested in this possible career path.

However I do feel like I’m approaching the starting line from an odd position without any art experience what so ever. The roadmap that I have compiled compromises of the various topics.

  1. Concepting, designing, prototyping, blockout
  2. Modeling
  3. UVing and Texturing
  4. Rigging and Animation
  5. Effects and Particle Systems
  6. Lighting and Cameras
  7. UI Art and Animation
  8. An “Elective Discipline” which I think I might enjoy either the shader or pipeline backend focus
    ADDEDDUM: Look for opportunities to streamline processes while learning / creating above.

However I do feel like this list is incredibly hefty as a possible new artist (or is it not?) given my current occupation with both school and side game development. Which brings me to several of questions that I would greatly appreciate being answered.

  1. How much focus should I put into these 8 different areas of art given my current time frame?
  2. How would my previous programming experience / computer science classes factor into my skill development as a technical artist?
  3. In what approach should I attempt to break into the role (straight into junior role, general game programmer, 3-D modeler)?
  4. How can I best leverage / compensate for my background?
  5. How much of game development experience with Unreal Engine will contribute to a well rounded portfolio for a job application? (Will touch upon almost every aspect including art with the friend throughout development)

Thank you for any answers in advance.

#2

I was a software developer for 18 years outside of the animation industry before I switched over and I think there is something to be said for learning the ropes of large scale software development outside of the environment of most studios. Since the deliverable for animation and vfx is the image, and not the software, sloppy code and quick fixes tend to be the norm. For game studios, I think it is better, especially if you are on the engine side of things, but I don’t have any experience there. Anyway, I feel like my development experience outside of the industry served me well.

This isn’t really answering your question about art experience, but I’m just saying don’t have tunnel vision when it comes to looking for your first job - there are plenty of opportunities related to graphics and 3D processing outside of the game/animation/vfx industry that may allow you to continue to improve you programming skills on the job, while you work on your artist skills outside of work.

#3

Take a look at the following:


I will say that you absolutely don’t need to come from an art background to be a technical artist, but it certainly helps. You also don’t need any formal development experience to be a technical artist, but again it helps.

While I went to an art school, I’ve never formally worked as an artist, I hopped over to tech art after a detour through level design. But I’ve used the same tools that artists use, and gone through the same pipelines that artists go through, and having that shared experience and shared language is incredibly valuable.

Also, keep in mind that tools engineers exist. You don’t have to be a tech artist to improve the lives and workflows of your team, just don’t forget that tools are written for the users, not the data.

2 Likes
#4

The list you have is basically equivalent to “all 3D art” - while it’s unrealistic to think that you’ll be able to master all of these elements when a person might devote their entire life to any one of them, it’s a very good idea to get a taste of all these disparate fields, and see which one you enjoy most. Having a wide knowledge is great, but in the end unless you’re applying to a small company, it’s likely you’ll be hired as a specialist in one of these disciplines, and it helps a great deal if it’s a discipline you like.

Getting a job as a full artist, be it modeller, painter, concept artist or animator, is hard. Crazy hard. One way or another, applying for one of these will have you up against incredible people, with years of experience ahead of you. I would say it makes more sense to play to your strengths, to get industry experience on the more technical side of things while refining your art in your own time at your own pace, than to try and catch up with those other people. Once you’re there, make friends with all the amazing artists who do whatever it is you want to do.

On that subject, a background in legit computer science will put you head and shoulders above all the people like me who learned mel script from youtube. One of the best things you can do is to pursue the development projects and apply those skills, see how they relate to the game environment.

And don’t worry about the lack of art training, there’s no gateway to it. As with everything, it just takes time and practice.

#5

I feel a little lazy saying this without providing a lot of context but hopefully this will be useful. I’ve seen too many tech artists who know how to write some code and have no clue about the pressing problems actually worth solving. Technical/coding skills are useless if you can’t effectively reason about what is the best place to apply them. And to do that you need to really know the art process or whatever problem space you are applying your solutions to.
If you can’t be your own customer how effective can you expect yourself to be?
So in short I’d say learn all the art. You can figure out the code stuff when you have actual concrete problems that you are solving.

3 Likes
#6

While I agree with you, an experienced software developer knows that it is less about the coding and more about the process of gathering requirements, asking the right questions, prototyping, proper testing, etc. that make for successful software. All of these things can be accomplished without out being an “artist” per se. So to the original poster I would say to worry less about improving your art ability as much as understanding the lingo and process of art, so that communicating with artists is unhindered.

3 Likes
#7

I appreciate your point of view mje11even and the fact that there are plenty of practicing technical artists with no art exprience definitely speaks to your point.
But, and this once again just being my opinion, I’d argue that’s an insufficient metric to aspire to. Mostly because both movie and game industries are notorious for terrible pipelines. I’ve never met an artist who’s been through a production who was actually happy with their tools. And I’ve met hundreds of them on every continent. In fact to quote some of the very best ones I worked with - “games are made not because of the tools but in spite of them”. And while there are different undertones to that statement I unfortunately believe the overall sentiment to be deserved.
So while asking people what their problems are and learning to understand them is a valid and important approach - a better one is knowing their problems better than they do. And on behalf of thousands of people who will not get to go home and see their families tonight because they are crunching on the latest movie or a game I have to say that we so desperately need better approaches.
Sorry for getting so dramatic :slight_smile:

#8

I get where you are coming from, but I will restate my point with the following illustration. At the animation studio I freelance with, it is almost a daily occurrence that a bug gets logged with a python error similar to “TypeError: cannot call … on ‘NoneType’ object”. This causes the tool to crash, the work to go unpublished, the frames to not be rendered, etc. etc. Basically a waste of artist time. Things like this occur not because the programmer doesn’t have an artist background, but because inexperience in coding, lack of testing, the speed of production, etc. I feel like these types of issues lead to pipeline hatred more so than artist-unfriendly and awkward tools. I don’t have quite the exposure it sounds like you have - I have only worked at two studios and only in feature length animation - so my view is limited.

#9

Hi @eriejar, and welcome to the forum! Im going to bring this thread a little bit back on track.

To each question: (in addition to the awesome links @bob.w provided :metal:)

  1. What is your area of focus? I started out as an animator and moved into technical art as a character TD. I think picking a couple of focus areas will help your learning path.

  2. I think it would be great - you’d add a very much needed CS sensibility and would be able to determine potential gotchas that art focused mindset may not be able to predict.

  3. I’d say first determine your area of focus in the TA domain space first and then scope the requirements for the level you feel appropriate for. From my experience associate TA or TA is generally the staring role. For me it was animator > tech animator > senior tech animator > senior tech artist.

  4. I’d say by grounding process against CS fundamentals and just listening to needs and problems - try to have the mindset of an artist and put yourself in their position.

  5. Fundamental knowledge is immensely powerful, understanding shaders, state flow, runtime system, skeletons will be very helpful. Generally smaller studios that take off-the-shelf engines will use them in their entirety whereas large studios will either gut them or build their own - so I’d advise not being too invested in unique things they do.

@d1ver & @mje11even - don’t want to stop your conversation but do feel you are veering off topic slightly - please feel free to start a new thread if need be.

2 Likes
#10

Thank you so much for this example @mje11even! And in general for standing on your point because I do believe this creates for some extremely valuable information for the OP here. Which is what we’re all here for :wink:

Honestly, your example couldn’t have set up the point I’m trying to get across better. What you are referring to is lack of technical competence of whoever setup that pipeline initially. Exception management is important. Not being technically incompetent is very important. In fact it is necessary.
But it’s not sufficient. The same way not setting a kitchen on fire does not make you a good cook.

Even when your code is technically impeccable, never crashes and runs super fast it is only as good as the substance of the problem it is solving. Technical competence will not make your solution better - it will just not make it worse. It’s a normalized multiplier on the leverage your idea provides.
Code is a tool the same way pencils or watercolors are. Yet the more sophisticated our tools get the more we tend to confuse them with the actual value that is being generated through them. You didn’t used to hear people say “I want to be an artist so I’m going to study pencils”, yet most people today say that “if you want to be a 3d artist you need to study 3ds max”. Which is both accurate and a gross misrepresentation because knowing how to use a 3d editor in no way indicates that someone is a good artist.

I’ve had the privilege to interview and hire some of best engineers, artists and technical artists in the world and hands down the biggest problem I kept seeing is that everyone is too focused on how to do things instead of having the deep competence on what is actually worth doing, expecting that someone will just tell them what to do.
And it sounds like a sound strategy when you are trying to get your foot in the door. But if you focus on solely maximizing you technical chops, many years in you’ll find that some artist on your team who can barely put two lines of python together is writing clunky tools that are getting a lot more adoption then yours are. Because code quality is always secondary to the leverage your tools provide. And it is something I really wish someone told me when I was starting out.

And I’m sorry for being the incendiary hipster radical that I am here :slight_smile: but I’ll leave @eriejar with this: you came to the currently working TAs to ask how you could best leverage your skills to create value in the market to get a job. And asking what everyone is doing or did is a way to do it. But a way to create a lot more value and find much more gainful employment would be to ask what is it that everyone is not doing that the market needs done. And the only way to know that is having core competence in the problem space you are trying to address.
Best of luck! :slight_smile:

#11

I’m not a TA yet but I’m at the other end of the same process you’re going through now (currently looking for a job if anyone needs an associate TA :smiley: snaik27.github.io , sorry for the shameless plug) . A couple years ago I decided I want to work in the games industry after learning some(read: very little) programming and modeling so I decided to make a game to learn the 8 topics you listed and your addendum. I finished about a week ago. If there’s two of us that thought to do the same thing, I’m sure there’s more so I hope this helps people in the same situation. My own background is at the end for some more context if you want it.

Here’s what I learned from 19ish months of solo development as a pseudo games education:

It isn’t impossible to learn all 8 + addendum things through the same project, but you need either understand the process and that it is probably going to take a couple years, or just not think about it. I did the latter. This was my “game” loop throughout development: learn -> apply -> iterate. I’ll break it down in terms of each of your points.

  1. Concepting/designing/prototyping/blockout: Watched every GDC/Unity/etc video I could on these topics, read “game design documents”, tried making my own, threw it out because what even, and eventually wrote out everything I could in Onenote and iterated on these things throughout the entirety of development. I thought it was “make a plan and execute”, it turned into “make a plan and destroy it a few hundred times”. I thought the game would take me 3 months, it took me 4 months to model my first character. Development took a full 19+ months.

  2. Modeling: I used blender so I can’t speak to Maya/Max/etc BUT get familiar with Maya/Max because Autodesk still runs the show for now and I should’ve taken advantage of free Maya before I graduated uni but I didn’t. Working on that now myself actually. Anyway, I ran through Blenderguru tutorials and tons of others, started modeling my character, threw it out, modeled again, threw it out, etc until I got to a level of fidelity that I both liked and felt was good for the constraints of VR and my own pc rig.

  3. UVs and Textures: Same as Modeling. UV unwrapping, imo, takes longer to understand for those of us without arts backgrounds but I kept bashing my head against the wall till the wall broke. Hand painted textures were out of reach for me because of my constraints of lack of fine arts skills and lack of money and time for something like a wacom. Substance is fricking sweet and so are all the other options out there like GIMP, photoshop, xnormal, quixel, textures.com/other free texture sites, etc. But learn the basics of making textures if possible. Again, Photoshop and Substance can be free at uni, luckily I got a year of substance from my uni so I learned there first but Photoshop is extremely important too and I didn’t realize until I started using it even though I used GIMP somewhat extensively before. Understand Texel density is super important to keep your visual fidelity consistent. Tri density, lighting, UV maps are also important for consistent visuals.

  4. Rigging and Animation: Again, used blender. Darrin Lile and Remington Graphics have great tutorials on these but here’s some things they don’t mention/stress enough: If you’re using Unity (I have no experience with Unreal), stick to the generic Humanoid skeleton structure. Naming conventions are un-understatably important even in a one man project, I can barely imagine how un-understatably important naming conventions are in large scale projects. That also applies to models and textures and shader properties and everything else that can be named. Make “control” bones as you need but don’t go “overboard” unless this is your TA-specialization. I did a bit and it was unnecessary and time consuming for what I was doing. Much of the rigging process can be automated if you have symmetrical rigs so here’s a good place to streamline.

  5. VFX (Effects and Particle Systems): You will most likely be authoring shaders in this area to fit your needs. VFX is my favorite right alongside tools. It is DEEP. Instead of following random tutorials here I followed tutorials for vfx that I needed in my game, made them again myself, threw them out, made them again, threw them out, etc. Go to this website: realtimevfx.com. Read, learn, apply, iterate. I made all my vfx using Unity, Blender, and Photoshop. Houdini is a thing and I really wish I learned Houdini but I didn’t really know anything about it till a couple months ago. It’s first on my list for next thing to use for my next project. There’s a dank Sea of Thieves talk on Houdini’s youtube if you wanna get a taste of it, go check it out. Same with Spiderman, that might be on the GDC channel.

  6. Lighting and Cameras. Here we get even further into fine arts imo. This is where “technical” knowledge was out of scope for me, the fine arts aspect is much more important. Textures are kind of similar, but an okay texture is good with great lighting. A great texture is almost worthless even with okay lighting. Learn colors, composition, and lighting theory. Then apply those ideas the best you can to your own game scenes. Blenderguru has great, software agnostic video lectures on these topics and you can always find more elsewhere. Can’t recommend anything more than his videos to get introduced though.

  7. UI Art and Animation: This one I have the least experience with directly. There are definitely a bunch of tips and tricks and an artistic background for sure helps a lot here BUT imo those things are all useful only on top of the foundation of a “UX mindset”, thinking about the “user”/“player”/“consumer”/etc. Look at UI in games you love, watch gdc talks, take mental or physical notes, and get an understanding of modern games UI design. I think most game UI design is terribly done because menus and lists and fancy animations and art are all fun to look at but if they don’t contribute to the overall game then what’s the point? I tried to address these things as diegetically as possible in my project and I failed miserably in many ways but again learn, apply, iterate is the motto. Mark Brown directly and indirectly touches on UI design a TON in his videos so watch all his videos .

  8. Shaders/Pipeline/“Elective Discipline”: Pipeline first. Watch tons of videos on developer pipelines, watch this video on tech art and this one . I wrote out a “plan” for a pipeline and then over the course of development replaced some parts of it because I was flat out wrong in my assumptions and approach. Definitely have a plan for what your pipeline looks like but also be flexible. Keep an open mind and mend your pipeline as needed. I don’t think any one thing prepared me for pipeline decisions so I can’t recommend any specific resource. It was more of combining my mindset as a programmer and my mindset as an artist to proactively avoid problems and reactively solve problems I didn’t predict. You might have an easier time than I did here since you’re studying CS at uni. Still, pipeline prep and pipeline problem solving was one of my favorite things because it sets the pace of work and to a large extent the fidelity of everything else. At least it did in my one man project, I’m not sure how it affects larger projects exactly. Some things scale, some things don’t. Watch every tech art video you can though. Andrew Maximov’s Tech Art Culture for Uncharted is great, I’ve probably seen it 5 times now. The Spiderman talks and the Sea of Thieves talk above are also awesome. Find every one you can. Now for shaders. This is the same as for vfx, but with a more problem-solvey “feel”. I made shaders like I made effects. Learn, apply, iterate. Follow tutorials, apply them to your effects, throw them out and remake them, repeat. At the same time, you can solve tons of problems with your shaders alongside making effects. Vertex animations, gameplay elements like a flashlight, foliage movement, etc. Fortnite has awesome shader tech for things like LODs and their building/breaking animations. Shaders and pipeline tools are my favorite things and although there wasn’t allllll that much I could do with shaders in my project, they’re fascinating. If this is where you want to specialize, I completely recommend going through the Real Time Rendering book (I’m doing this now) alongside your actual shader work. I’m sure you already know how useful it is to know how code interacts with the CPU, it’s the same with shaders interacting with the GPU. Having a more complete set of concepts to round out your knowledge is always useful so you don’t feel like you’re walking around in the dark (as much).

I don’t have answers for the set of questions you have because I’m because I’m not qualified but I hope this semi-breakdown of my own experience and process helps in some way.

My background: I went to school because everyone told me to go, hated it and jumped around majors till my 4th year in school and did Sociology. Looking back on it, it’s the best major I could’ve picked, I needed to understand more about people before deciding on any form of a career path. Started learning to program after my 3rd year and modeling during my 4th year. Unrepressed the idea that games can’t be a career and then started my solo project in November of my 5th year (had medical issues in my 3rd/4th year that forced me to stay a 5th). I’m now almost exactly a year out of school. Spending ~90% of the last year in my room at home has been an awesome experience but I get that it’s not for everyone and it’s definitely not even an option for most people so I get how lucky I am to have such an experience. I’m here for games as art, as play, and as competition.

Anyway hope this helps, excuse me for making it so long but honestly I needed to write this out anyway and it helped put a lot into perspective for me. If you have any questions, I’m happy to answer them if I can.

Side note: Everything that’s in quotes has a bunch of different meanings to different people so I put them in quotes.

1 Like