Hehe...installing Win7 can be sometimes really pain in the @$$. Why don't you give a try on Win 8? By the way, that EFI stuff has some workarounds, but at this moment I can't recall what I did, when I installed Win7 on my computer. But, I have to admit, Win7 is rocksolid (to me) I had no BSOD since I replaced my memory modules
From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Stefan Andersson Sent: Wednesday, May 15, 2013 9:28 PM To: softimage@listproc.autodesk.com Subject: Re: Texture size in games? Again, thanks everyone for the feedback. Really helpful information. Faith has it that I'm not suposed to actually give this a try... Tried to install Win7 on my HP machine, and it messed up my EFI boot manager. So nothing would boot up. And I'm really bad at error searching Windows errors. So I'm installing CentOS again, need some familiar ground before making another attempt. With that said, I still think I will make some sort of attempt at creating some "game ready" "award winning" "AAA class" models :) regards stefan On Wed, May 15, 2013 at 11:26 AM, Martin <furik...@gmail.com> wrote: One thing that is very different from rendering works, is that you need to be very clean with your data, naming convetion may be more important, history and alive operators are not welcome. Basic scripting skills helps a lot even if you're not a TD, and specially if your company doesn't have too many TDs or no TDs at all. My workflow and my team workflow improved a lot when I learned a few scripting tricks. My data is cleaner and my clients happier. So, if you can't script, I really recommend you to learn some basic things. Basic scripting is more useful than ICE here, if you have to choose one. About mipmap, Mipmap generation is automatic. The format depends on your project. DDS is almost the standard in a lot of projects I've been involved. Some using Nvidia plugins, some other propietary tools but DDS has been quite the standard lately. Last time I did a Nintendo platform project we were using NW4C TGA. A format that comes with the Nintendo Tools package. Modeling software also changes depending on the project because the programmers may write their tools based only on one software. In Japan, Maya and Softimage are the most used. You need to match your client's version too, here is where Autodesk old version policies screw you if you have a subscription, 3 previous versions are not enough !! But most of the time we use 3 years versions (right now we are using SI 2011 in my current project). I haven't seen a single project based on Blender, but it doesn't mean that you can't use it, you just have to convert it to your client's software when you deliver your work. And here is where you'll have to learn how to live with conversions. They aren't as simple as we would like to. Sometimes you'll have to try FBX, Collada, Crosswalk, OBJ, because depending on the case one can be better than the other. And after that, you'll have to clean that data, because converted data have a lot of garbage. Here is where your scripting skills will save you hours of work. Specially if you need to convert animations. In no-SI projects, I usually do 80% of my modeling work in SI, convert it to Maya or Max and finish it there. M.Yara On Wed, May 15, 2013 at 5:52 PM, Stefan Andersson <sander...@gmail.com> wrote: Great response everyone! Except for polycounts and fascist UV mapping, it more or less sounds similar in a lot of ways to what I'm already doing. I wont go into games trying to become a programmer, I do want to make art. But as Matt suggested, I'm more likely to go art/tech since I'm somewhat of a geek also. Mip mapping is something that I'm familiar with, and my own asset tools already have it in place that I convert with OIIO all textures to be mip-mapped and also the power of two (just because I don't trust anyone I also resize them). But doing mip-mapping for a game engine, does that requires to export each level? Or what image formats are usually used for doing mip-mapping? I can't see game engines using exr... or do they? :) Before I go on and make Matt's little exercise I think I will build something rigid and see how that looks. And I have to convert my workstation from Linux to Windows. I talked to my brother who is working at Massive, and he thinks I'm an idiot... but he also said that they base the size of the texture depending on meters in the engine. I guess it also depends a lot of which engine you will use. But it leads me to another question. I'm not 100% sure yet which modeling software I will be using. My 14+ years with both Maya / Softimage leaves me somewhat in the middle of those two. Blender is also a contender, but I'll stick with the programs that I know from inside and out. However, Softimage doesn't have any metric units. Would the usual assumtion that 1 SI unit is 10 cm still apply? or again... depends on the engine/exporter? all the best! your humble servant stefan On Wed, May 15, 2013 at 10:26 AM, Matt Lind <ml...@carbinestudios.com> wrote: 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 -- Stefan Andersson | Digital Janitor | Generalist for hire blog <http://sanders3d.wordpress.com> | showreel <http://www.youtube.com/watch?v=qVb8yvxZcss> | twitter <http://twitter.com/sanders3d> | LinkedIn <http://www.linkedin.com/in/sanders3d> | Instagram <http://instagram.com/sanders3d_> | cell: +46-73-6268850 <tel:%2B46-73-6268850> | skype:sanders3d -- Stefan Andersson | Digital Janitor | Generalist for hire blog <http://sanders3d.wordpress.com> | showreel <http://www.youtube.com/watch?v=qVb8yvxZcss> | twitter <http://twitter.com/sanders3d> | LinkedIn <http://www.linkedin.com/in/sanders3d> | Instagram <http://instagram.com/sanders3d_> | cell: +46-73-6268850 | skype:sanders3d
