Well, you can look at it from two different points of view: a) Do what many game artists do and brute force their way through making content with heavy iteration.
b) Do what many game programmers do and try to be efficient. If you just want a job in games, follow path A which doesn't really require much learning on your part, but does require a lot of practice. You need to follow the specs for whatever engine you're developing content for, and be frugal with whatever resources you have available to make the content. The specs are project specific and change frequently. Therefore, pick an engine and make something to function within it. then choose a different engine and try to make the content function in that one too. You'll quickly learn making functional content can be very difficult and is a skillset of itself. Following course B, anything a game programmer is going to tell you in making art is how to make the end result efficient for his needs. he doesn't give a crap how many hours you spend on it or what it looks like. He just wants it packaged in a tiny efficient form that doesn't blow up during runtime or induces expensive resources. Since programmers are not artists, they don't know you want screenspace ambient occlusion, or fancy pixel based shading effects, or whatever. In fact, they prefer you not use them because they want the CPU/GPU time for themselves to improve gameplay and other engine specific functions. So, if you want to make good art, retain sanity, and do a good job, your best bet is to starting learning computer science / computer architecture and apply the knowledge towards your artwork. That is how the more successful game artists rise through the ranks as they are the ones that approach the programmers and suggest how art can be made better and more efficiently by applying technical knowledge to their art techniques. If you rely on the programmer to figure it all out, you're going to be in for a lot of pain and feel unfulfilled by working in a very confined box. If you rely on other artists to figure it out, you'll be in for even more pain as the chaos from lack of technical knowledge resulting in brute force techniques will drive you crazy. first assignment: Start with modeling. The goal is to make the most robust looking bipedal character mesh that can be animated (deformed like an envelope) while being extremely frugal with polygon count. Say, and entire seamless mesh at less than 5,000 polygons - triangles and quads only. Keep iterating on it until you cannot find anything to iterate on anymore. then, pretend a programmer enters your space and gives you a tongue lashing for exceeding the polygon count. So redo the asset with a new polygon limit of 1,000 polygons. sounds harsh, but as you do it, you'll discover things on the 1,000 polygon version that could be applied to the 5,000 polygon version you wouldn't have thought of until you were forced into the situation. Basically its an excercise in determining artistic priorities. once you reach the 1,000 polygon version satisfactorily, change the criteria to 400 polygons. Once you finish the 400 polygon version, take what you learned and apply it back to the 5,000 polyg! on version. Actual polygon counts used in production vary with the platform and title. Example: a boxing game on a console will probably throw 50K polygons or more at the characters because the environment is small and few subjects of interest. An MMORPG running on a PC will devote under 10K per character because the worlds are large and there are many characters sharing the computing resources. An embedded game running on a phone or tablet will probably use significantly less as the computing power is also much less. Once you finish modeling, apply an envelope with nulls as deformers, but limit yourself to 30 nulls for the entire character. now make him bend and deform as expected with those 30 nulls and limit each vertex to being assigned to 4 bones/nulls or less - and that's a hard limit. Now do that to the 5000 polygon, 1000 polygon and 400 polygon versions of the character so each looks as similar as possible to the others - including fingers and toes. Notice how each behaves and must be constructed differently to reach the same end result. Now you'll discover how you must retopologize your geometry - so take what you learned and start over again with the modeling. As for rendering....assume each texture applied consumes a render batch. Think of batches as render passes performed on the GPU. Each batch has a certain amount of setup cost which is often more expensive than the time spent rendering the contents of the batch. Therefore it's critically important to minimize the number of batches you induce on the GPU. Assume each light, shadow, and unique material induces a batch. The name of the game is to create that character fully textured and lit using only 4 batches with full normal mapping, cast shadows, and realtime lighting. Texture images must be square with dimensions measuring a power of 2 (64, 128, 256, 512, 1024, etc...). You can use one image map, and one normal map. Again, specifics vary with platform and title. The emphasis here is to teach you how to prioritize and be efficient. Matt ________________________________________ From: softimage-boun...@listproc.autodesk.com [softimage-boun...@listproc.autodesk.com] On Behalf Of Stefan Andersson [sander...@gmail.com] Sent: Tuesday, May 14, 2013 11:46 PM To: softimage@listproc.autodesk.com Subject: Re: Texture size in games? Also, if and old dog like me that knows everything and nothing, where would be the best starting point? Conversion of "knowledge". Or rather "don't learn this, totally useless" :) Regards Stefan -- Sent from a phone booth in purgatory On May 15, 2013, at 8:31, Stefan Andersson <sander...@gmail.com> wrote: > Hi all! > This might be a strange question, but what would be the normal texture > size today when creating content for games? > I'm trying to learn a new profession and need to test out the basics > at home before I jump out into the void :) > > Also, would unity be a good practice platform? Or any other recommendations? > > I'm trying out something new here, so any suggestions and tips are welcomed! > > Best regards > Stefan > > > -- Sent from a phone booth in purgatory
