Re: Texture size in games?

869 views
Skip to first unread message

Stefan Andersson

unread,
May 15, 2013, 2:46:28 AM5/15/13
to soft...@listproc.autodesk.com
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 <sand...@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

unread,
May 15, 2013, 2:31:24 AM5/15/13
to soft...@listproc.autodesk.com

Stefan Kubicek

unread,
May 15, 2013, 3:58:29 AM5/15/13
to soft...@listproc.autodesk.com
I haven't had much to do with games for the last two years so some info
might be outdated already, but Unity seems to be a good starting point
both in terms of features and affordability.

As for textures, it totally depends on what type of asset you want to
build, and for which Platform (Hardware).
A typical character texture set three years ago (diffuse and normal map,
maybe specularity map and AO map too if needed) used to be 512x512 in
resolution for the head and hands and another 512x512 texture set for the
body (usually you want higher texture detail on the face if it's seen
close-up), plus the same again for the body. These days it has most likely
quadrupled for modern hardware.

I've also seen combinations of resolutions where the diffuse texture would
only be half the size of the normal map (if the diffuse texture is
low-freuqent compared to the normal map for example), and vice versa, it
depends on what maps contain the look-defining detail.

Good practice is to use textures with resolutions of the power of two
(128x128,256x256,512x512,1024x1024), since depending on engine and target
hardware non-power-of-two
textures are often scaled up the the nearest power of two automatically,
consuming the same amount of RAM, but not offering anymore precious
detail. There are exceptions to this rule, on Wii for example you may use
combinations of power of two and non-power-of-two textures, like 256x512,
without wasting any RAM (textures are not automatically scaled to power of
two).

If you are using texture baking, and the engine makes use of mip mapping
(as most do) make sure to keep the individual islands far enough apart
from each other so they don't bleed into each other when scaled down in
the mip map creation process. Choose a suitable fill color (one with low
contrast to the surrounding baked color information) too for the same
reason.

For skinned geometry use as little a number of skin weights as possible,
most engines have special code paths for fast deformation of various
numbers of skin weights per vertex (e.g. 1, 4, 8, but not 3,5 or 7), as
well as the maximum number of joints deforming a single mesh (e.g. 64),
though I'm sure on modern hardware the latter is not so much of a concern
anymore. I found 4 skin weights per vertex to be sufficient for pretty
much anything, including joint-driven facial animation).

I'm sure there are tons of tutorials covering all those aspects, also in
regards to Unity, different engines and hardware may have different needs
or specialities.
--
-------------------------------------------
Stefan Kubicek
-------------------------------------------
keyvis digital imagery
Alfred Feierfeilstraᅵe 3
A-2380 Perchtoldsdorf bei Wien
Phone: +43/699/12614231
www.keyvis.at ste...@keyvis.at
-- This email and its attachments are --
--confidential and for the recipient only--

Szabolcs Matefy

unread,
May 15, 2013, 4:04:04 AM5/15/13
to soft...@listproc.autodesk.com
Hi

As a game artist it's very hard to really answer :D

I used to make my textures usually in 2k*2k and downsize for the needs.
Usually I meet always requests, like the texture is good, could you make
it in bigger res? So a 2k is a safe size, you can deliver any size
fitting to the rule of power of two (16, 32, 64, 128, 256, 512, 1024,
2048).

Unity is a cool engine, and there are many users, and companies using
it, so you are on a safe ground, if you learn it. However, I might
suggest you to learn Unreal too, or CryEngine (I'm Crytek employee :D ).
Of course knowing an engine will help to learn others, and you might
learn the workflow of game development in any engine, but of course the
workflow depends on the company you work for too. Like, Naughty Dog has
no level editor, but Maya is used for art authoring, but AI lighting,
etc is made in their own editor. So it really depends on the company.

Cheers

Martin

unread,
May 15, 2013, 4:06:10 AM5/15/13
to soft...@listproc.autodesk.com
Hi Stefan, 

I don't think there is a "normal" size.

It will depend on your platform specs and type of game. If it's a fighting game, you may use more resources because it will display less characters at the same time than a strategy game.

In a fight game for PS3, we used 1024 for the body and 512 for the face in the final DDS texture. Normal, Specular Map and Color only. I think the polygon count was about 20.000 ~ 25.000 per character.
The PSD data was made in 2048, 1024 i think. We usually work with doubled resolution because you never know when the specs will change, or if you'll have a sequel with better specs, or you'll have to change UVs drastically and bake your texture to your new UV.

In an arcade game we used a lot of textures per character, 512 for the eye, 1024 for the face, 1024 for the hair, and the rest, as many 1024 pics as needed as long it didn't exceed 20Mb, (or was it 15?)
Color specular, color and normal this time.

For the last 3DS game we did, it was like 128 x 7 textures. This game had interchangable parts so it had a 128x128 limit per part. and about 7000 polys per char.
Here we used doubled resolution too in our PSD source, but some details needed dot level edition in the final resolution.

Only 2 ~ 4 bones deformers per point, weights without decimals (Maya) or power of 10 (SI), T pose for characters, no more than xx bones(null bones) per char, irregular UVs and tex.size (bigger UVs for details like a character eyes, etc), no more than x lights per scene, etc. are quite common limitations. Real Time shaders aren't as good as working with pre-render stuff, so we need to cover that by painting a little more the textures. (ex, usually you don't have real time occlusion so you have to paint it, or bake it), sometimes you have to try to overlap your UVs so it will look like you are using a bigger texture (like tiling some parts).

Another thing about mipmaping, with the automatic down scaling you'll see seams be sure to bleed your textures outside your UV islands.

Like I said, it depends, and you'll have to learn to deal with those limits.

BTW, depending on the programmer skill, you may be able to use more or less tex.resolution and polygons.

Unity? It will also depend in what do you want to do.
If you're going to create assets only, chances are your client will use a different engine so your unity skills won't be that useful.
Modeling, sculpting, weighting, texturing, animation, rigging and scripting skills would be better.

If you're going to do everything (assets, programming, game planning, etc) by yourself or with a small team, I think Unity could be very friendly for a small project.

GL

M.Yara

Szabolcs Matefy

unread,
May 15, 2013, 4:19:51 AM5/15/13
to soft...@listproc.autodesk.com

And if we are technical details, number of vertex data matter a lot (depending on engine of course) So the number of UV islands, hard edges, materials are affecting performance too. And the texture compression too. I was working on several games when I was working as a freelancer, and there were plenty of technical requirements that were not the same at the different client. For example, there were a client with the requirement to delete the blue channel from the normal map, and swap the red and blue channels. Or, there were another one, who required BUMP texture in the diffuse color alpha…

 

When I did characters for FPS game, we made a head texture (512 for the head) and a body (1024) and an equipment. Alpha channel was used for opacity (alpha tested), and specular was R channel for specular, G for Glossiness

 

If you just want to learn game development, visit gameartisans.org, game-artist.net, polycount etc. If you have specific companies you would like to work for, study their workflow, and tools.

Matt Lind

unread,
May 15, 2013, 4:26:31 AM5/15/13
to soft...@listproc.autodesk.com
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: softimag...@listproc.autodesk.com [softimag...@listproc.autodesk.com] On Behalf Of Stefan Andersson [sand...@gmail.com]
Sent: Tuesday, May 14, 2013 11:46 PM
To: soft...@listproc.autodesk.com
Subject: Re: Texture size in games?

Szabolcs Matefy

unread,
May 15, 2013, 4:47:48 AM5/15/13
to soft...@listproc.autodesk.com
Very good writing Matt, I love the part you wrote about the 5000-1000-400-5000 method! :)

And in addition, our game engine was really sensitive to vertex data (UV island borders, hard edges doubled the vertex data, and sometimes the drawcall as well), and lead artist was sensitive to the UV coverage ration, and the pixel density as well. So game art is not an easy art :D

Stefan Andersson

unread,
May 15, 2013, 4:52:07 AM5/15/13
to soft...@listproc.autodesk.com
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



--
Stefan Andersson | Digital Janitor | Generalist for hire
blog | showreel | twitter | LinkedIn | Instagram | cell: +46-73-6268850 | skype:sanders3d


Szabolcs Matefy

unread,
May 15, 2013, 5:14:27 AM5/15/13
to soft...@listproc.autodesk.com

We use SI for 1unit = 1 m. That’s our habit :D But it depends on the exporter. If you use FBX for games, you might use any scale like 1 unit = 10 cm, etc. Mipmapping, and UV mapping for mipmapping is real pain in the artist ass :D I recall debates with lead artist, who insisted that I should move the islands closer to make more coverage in the UV space, after that insisted to move them apart, to avoid mipmap borders appearing on UV borders…

Martin

unread,
May 15, 2013, 5:26:37 AM5/15/13
to soft...@listproc.autodesk.com
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

Stefan Andersson

unread,
May 15, 2013, 3:28:27 PM5/15/13
to soft...@listproc.autodesk.com
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

Szabolcs Matefy

unread,
May 16, 2013, 7:56:13 AM5/16/13
to soft...@listproc.autodesk.com

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

Stefan Andersson

unread,
May 16, 2013, 8:25:35 AM5/16/13
to soft...@listproc.autodesk.com
I would like to keep my sanity intact, and from the videos that I've seen from Win8 I think I will not go down that route. I read quickly on the web and others have had the exact same problem as me with corrupt EFI install (and also with HP workstations), but no solutions :(

I'll make another attempt this weekend, and I'll make a USB installer instead of the DVD.

regards
stefan




Mirko Jankovic

unread,
May 16, 2013, 8:42:20 AM5/16/13
to soft...@listproc.autodesk.com
Actualy win 8 turned out to be pretty good. 
If you ignore metro completely for example with start8 or similar programs taht gets you back that start button. working exactly as like it is win7 but with couple more performance boost.
especially if you are running new hardware, ssd and stuff like that, support is better.

Szabolcs Matefy

unread,
May 16, 2013, 9:20:44 AM5/16/13
to soft...@listproc.autodesk.com

I tell you that I tried first USB Install, and sucked, then DVD install, and sucked. The third attempt was successful, but I really can’t recall what I did. I think I disabled that UEFI thing at all, to make me no trouble anymore. Now I am considering Win8 especially because it is said that it’s more reliable and better in performance.

 

Good luck (prepare some pills before you attempt :D )

 

Cheers

Stefan Andersson

unread,
May 16, 2013, 11:47:36 AM5/16/13
to soft...@listproc.autodesk.com
I'm just assuming that it was the pills that made you forget about the procedure :)

I'm more of a beer person, I'll prep the fridge before next attempt.

Regards
Stefan 

-- Sent from a phone booth in purgatory
Reply all
Reply to author
Forward
0 new messages