How deep into gaming engines do you need to be?
As professional 3D modelers, do you spend time studying the workings of game engines or does the basic input/output and lighting setup for tests suffice to do your work? I'm asking this since i'm new to the area of gaming art. I have a generic modeling and texturing background and to be honest its a bit scary to think i have to learn UDK or Unity coding from scratch to a high level like a game programmer, specially with the tales of how UDK makes a hassle of simple stuff like importing of assets etc.
And btw, not wanting to start any dividing topic, how transferable is the knowlege of UDK to Unity and vice versa? Are they so different that you need to start from zero if you happen to get work with a company that uses the other?
And finally, a really noobish question, but these days, what is the engine most used for indy 3d games that come out? Or Android/IOS? At first i'd assume Unity, but curiously UDK seems to have a better licencing deal for small business so i'm kind of confused.
Thanks mates!
And btw, not wanting to start any dividing topic, how transferable is the knowlege of UDK to Unity and vice versa? Are they so different that you need to start from zero if you happen to get work with a company that uses the other?
And finally, a really noobish question, but these days, what is the engine most used for indy 3d games that come out? Or Android/IOS? At first i'd assume Unity, but curiously UDK seems to have a better licencing deal for small business so i'm kind of confused.
Thanks mates!
Replies
2) What's going on is always transferable, I have entity, entity has normal. That stuff transfers. Exactly how you make an enemy move or exactly what you need to do to apply a normal, that stuff doesn't.
3) On mobile people love Starling/Sparrow, personally I prefer to do it myself a little more as I want lots of performance and those libraries are wasting time and energy on features I don't want/need. UDK is mostly preferred by bigger projects although Unity is garnering a following, to me I don't like Unity I don't feel like I have tight enough control.
At both of my jobs the engine was all in house and everything was learned on the job. But knowing how to import meshes, create basic shaders, setup levels and do lighting pass in an engine helps you a great deal when it comes to being able to pick up the same concepts in house. Everything is transferable.
Even as a Tech Artist there can be plenty of work to go around with rigging, lighting, optimizations, material setups, etc. before you cross the code/scripting-barrier.
But do you mean 'how well do I need to know the editor'?
That depends on tools, the studio, and the division of labor.
Character artists can often get away with doing just enough to get their work into the hands of animators/riggers, who take it from there. Prop artists can sometimes get away with only building their props and then handing it to the level builders. Some places have hybrid layout artists/env artists/lighting artists/etc. But, yes, most everyone will be touching the game toolset at least a little for some part of their job.
Often times MOST of the learning happens on the job..especially if youre talking proprietary tech, like others have mentioned. But that's not an excuse for avoiding UDK or unity and just tinkering a little now and then. The concepts transfer, even if terminology differs.
And, really, UDK isn't so bad. It's complex, sure, but if you can use a program like Max or Maya, the basics of UDK are not beyond you. Start small: getting an asset in and lit for your portfolio or something and goodluck!
Being a 3d-artist in the game industry also means that you're doing very technical things as well. You don't need to know everything about how it works and it's something you'll learn on the job but it's always handy to have some before starting to work as well. You'll start to understand a little bit more about games in general and how the underlaying code that affects it.
You don't need to know how to write the code itself, but it's good to have the basic understanding of how it works. If you can wrap your head around basic things like the different Programming Paradigms and simple programming statements. You'll also soon a super basic knowledge of why certain things work in-game and why some things don't. Or why they would be too expensive to use.
Example Scenario: You have a perfectly working environment in your game, both players and AI are running around on it. For some reason the performance drops super-low when the players and AI shoot eachother with the shotgun but with not with any other weapon.
Example Solution: When shooting the shotgun the game calculated where each pellet would go and where they hit the hitboxes of the player models. Thus doing different types of damage on different parts of the bodies at the same time. Several players and AI doing this on each other at once caused the slowdowns. Solution was to switch the hit-detection of the shotgun to something like 1 ball that expanded over distance but did less damage depending on how long it took for it to reach its' target. 1 thing to calculate over 20 things to calculate at once. (which could also hit different players, surfaces, walls, water etc)
It's not necessary to know this stuff, but it's good. Since then you can communicate a little bit easier with scripters & programmers. Asking them about things like that is always nice too, since most of the programmers I've met, love to explain these things to others as well but it's hopeless to explain these types of functionalities when they have to explain every little thing so that you can understand how it works.
It's always good to learn how to use game editors. Importing assets into editors is a must but it's still something you'll learn during the first days of the job. It all depends on what you do, but don't limit yourself. You have great game editors out there for free, why limit yourself to staying inside a maya/max + model-viewer only? You can create great interactive environments with the tools that are out there.
Being a 3d-artist is great, it's a lot of fun and you solve a lot of problems, not just art-related ones but very technical ones as well. In this case it might be a little bit too extreme, and you won't deal with stuff like that on a daily basis. You will however have pure art-technical issues that you will need to solve most days.
http://www.polycount.com/forum/showthread.php?t=110010
By this I do not just mean how to import and slap on textures - but how to properly set up materials; multi-sub materials; light maps; animated materials; lighting and shadows; simple effects like wind, sparks, smoke or glow. Possibly even simple animation.
This could sound daunting if your starting from scratch, but individually all these things are quite simple in any major game engine. Just take the time to learn them as you come across them and build up a skillset. This kind of stuff helps present your Art better and gives you a cursory understanding of how your props or characters will be applied in a game.
I want to add finally that if you're looking at a job where you have to learn new tools in an area your not totally comfortable with, don't worry, you should get at least some training in in house tools and in my experience, working with the most complicated POS software day in and out in a professional work environment around other pros will make you a master quickly.
So in UDK or CryEngine you just drop and go, there could be a lot more work that needs to be done. Mostly because they are looking to make the engines functional and not bulletproof so they can sell them to other companies, the product is the game not the engine so they tend to be a little rougher around the edges.
What really broadens your understanding of how engines operate, is going through those rough around the edges challenges and figuring them out.
http://wiki.polycount.com/CategoryTechnology
How the meshes and textures are stored and moved around in memory (i.e. what makes them efficient for the game engine - tri-stripping, vertex splits, etc).
How they're rendered (again, what the efficient methods are and when to use which - batching, instancing, fill rate, occlusion, portals, culling, draw calls, etc).
Multiple ways around common issues (things like alpha sorting issues and ways they can be worked around - alpha test? two passes? forced rendering order? alpha to coverage?).
Ultimately, it's about being a better game artist than knowing an engine better. They're things that are useful to be aware of when creating the artwork before it ever sees the engine because chances are they'll be of benefit no matter what engine you wind up using.
A lot of game development is being able to problem solve or to find good ways around an issue if you can't fix it straight up. If you can predict it's going to be a problem, you can ensure that you know ways around them or you can build stuff in such a way that it's easy to go back and edit things.
But you're only ever going to learn those things by putting stuff into an engine and seeing it break - so it's an iterative process :P
Systems Programmer
-
-
Graphics programmer
-
-
Technical artist
-
-
Game artist
-
-
Traditional Artist
Not to imply heirarchy but to imply a ratio of the 'level of required knowledge in engine' Vs 'ability to make pretty looking stuff' There's a place for everyone on that spectrum in a game studio you just have to accept where you lie. I consider myself more of a technical artist (my day job is programming for frigs sake)
I have to be able to make pretty stuff and know the engine in equal measure. But because of that I'm a reference point, when people on my indie team need to make a model I'm telling the things they need to know so they can focus on being better artists than me. They still need to know something though, I don't want to spend all day explaining why covering your model in U/V seams is a bad idea. Additionaly when a systems programmer is like "I need to make a dynamically sized wall... how's that supposed to work with the model" I can tell him the different approaches the artists could use and we'll select one that works well.
could you elaborate on this statement? specifically how could I lean more about how shaders affect my work?
For example, want to fake a 'rough' rocky surface on the cheap? Half-Lambert, Phong with a low Gloss and very faint Spec, standard option for almost all engines. Some artist go through their entire life not knowing how to setup proper looking 'cloth' or 'velvet' materials, even in premade stuff in MR or VRAY.
http://www.neilblevins.com/cg_education/cg_education.htm
The materials and shaders sections of Neil's site are helpful in understanding how to break the materials down into their basic elements. Little changes between the engines other than names and possibly some procedures for various game related technical issues. So it's a good place to start. The game related technical Mumbo-jumbo is nice to know but almost always on the job knowledge that no on expects you to know, the theories behind material break down and recreation are critical.