Home Technical Talk

current gen standards

ngon master
Offline / Send Message
almighty_gir ngon master
i realise that this is largely engine specific, however i figured it could make for good conversation too.

i was wondering what "current gen" standards for polycount, and texture size are? i've seen games that have what seems to be low polygonal budget, but huge detailed textures, and i've seen the opposite.
i've seen the headshots from games like uncharted 2, and i've seen meshes from games like metal gear solid.

so i was wondering. with todays capabilities, what's more important to focus on? low polygon budgets? or polyflow? should we be aiming for 800 tri's per head? or not worry at all and make the most animation friendly loops known to mankind?

Replies

  • Realm
    Good questions. I find it ironic that the texture techniques created to help save polys are the current culprits in many cases of causing poor performance - multiple textures, large normal maps, etc.

    I think like you said, it's somewhat engine specific, but it's also project specific. Depending on what is most important to see in the game, you may trade one for the other to save performance. Personally, I try to sneak in extra loops and faces to give more depth and better deformations.
  • Joshua Stubbles
    Offline / Send Message
    Joshua Stubbles polycounter lvl 19
    Geometry always has been and will be cheaper to render than texture data. I would always suggest more geometry over larger textures. But again, that's very specific to the engine or type of game.
  • Mark Dygert
    IT's not so much engine specific. Its all about context. As Eric is fond of saying "go talk to your graphics programer" heh.

    In UDK you can create a 3D cartoony side scroller or a free roaming FPS. Even deeper than that and its more important to concentrate on the priority of the object and its relationship to the player/camera. If its a trash can they hide behind in a on the rails shooter or a trash can in a top down RTS game its going to be handled differently.

    There has been a lot of automation and auto-generation of LODs that makes switching those priorities easier so its not too difficult to down res, but its nearly impossible to up-res past what the artist creates. For me its easier to work smartly knowing it could be down-res'ed but its really hard for me to try and up-res something after the fact without having to redo it.

    With typical high poly work flows you still need to take these things into account but you're almost always creating something that will never be displayed in game, and creating another lower LOD isn't that difficult to do.

    You might need to trim some polys out so working in edges and loops is probably better than tris. Loops and rings are easier to remove without effecting the UV's or skin weighting but tris normally have to be welded or removed which normally effects the UV layout and almost always screws up the skin weighting.

    BUT More typically you're textures might get down res'ed so don't pack tiny details onto huge maps that will lose all detail at smaller sizes, stay away from one pixel lines and noisy textures.

    You have to keep in mind that screenshots are just a moment in time, that might of been pre-production and not final art, it might of been the highest or a mid level LOD.

    So its smart to get a sense for the genre and the specific area you're creating and then keep in mind that Do whats best for whatever you're working on... and get ready to rework it later if you didn't plan properly or something outside of your control changes.
  • ivars
    Offline / Send Message
    ivars polycounter lvl 15
    I'd say if it's personal/portfolio art just worry about the looks. Add that extra geometry or use high res textures if it makes it look better.

    If you're making it for a real application, find out your limitations by talking to the programmers, do tests, read up on documentation and as been mentioned; be ready to rework things if needed.
  • almighty_gir
    Offline / Send Message
    almighty_gir ngon master
    Vig, is there any possibility that i can get you to stand over my shoulder and give realtime critiques for like... a day?

    i feel like it would probably improve my work 100x more than working for a year without it :P
  • Snader
    Offline / Send Message
    Snader polycounter lvl 15
    Unfortunately, Vig only does personal training in return for sexual favours and he's very, very picky.

    On topic, here are two relevant articles:
    http://www.rsart.co.uk/2006/11/20/how-many-polygons-in-a-piece-of-string
    http://www.rsart.co.uk/2007/08/27/yes-but-how-many-polygons
    Ofcourse these aren't all 'current gen' but it shows how a lot of factors influence the budgets.

    GTA IV has NPCs walking around at about 3000-4000 polies, while Drake's Fortune's Drake is made up of roughly 10 times as much.

    A couple of factors to take into consideration:
    -perspective/viewpoint (first person, over shoulder, topdown, on rails)
    -amount of objects/characters (fighting game only has 2 characters, FPS generally a handful, RTS have a shitton)
    -importance of object/character (main character, unimportant character, generic crate)
    -size of object/character (empty beerbottle, human, tank, skyscraper)
    -complexity of object/character (human, slimeblob, mech warrior, and desert,city,jungle)

    A jungle can use relatively few textures and polygons by using lots of planes, but there's a lot of transparancy causing overdraw, whereas a city would show tiling more noticeable and thus needs some creative way of blending - but has virtually no alpha transparency in the textures.

    A wall is generally a very simple (flat plane even) shape so it needs very few polies. But because of the size it will need large textures (and possibly parallax mapping and a fancy material) when compared to a NPC - who'll use more polies but a simpler texture.

    Generally, it's a good idea to use nice edgeloops because, as said, it's really easy to remove polies or smooth out with a chamfer. So your model might not be 100% super optimized, but it gets decent results without the optimization being a huge timesink.
  • imperator_dk
    Offline / Send Message
    imperator_dk polycounter lvl 10
    Long and thin tris are typically a greater issue on current consoles than the number of tris as such. The longer and thinner your tris the larger the number of pixels you end up rendering twice eating up your fillrate.
  • Eric Chadwick
    More here (now incl. this thread!)... especially check out the Beyond3D link.
    http://wiki.polycount.com/PolygonCount#Typical_Triangle_Counts
  • Autocon
    Offline / Send Message
    Autocon polycounter lvl 15
    For the current generation of consoles from what I have seen the biggest limiting factor is not polycount or even texture resolution but how complex your shaders are. Obviously having huge textures dose effect this but its the complexity of the shaders that really are the biggest limiting factor today.
  • warby
    Offline / Send Message
    warby polycounter lvl 18
    neither texture size nor polyocunt is usually the bottleneck but drawcalls and overdraw(fillrate-bound gpu) !

    here are a couple of good rules of thumbs:
    -use as few materials as possible !
    -use atlas maps to get many small items together in one texture/material/shader
    -batch a lot of small objects together on run time to reduce drawcall amount
    -99% of your scene should use one and the same shader ! switching from one drawcall to the next has different amounts of overhead depending if its a different shader or not !
    -so even if you cant batch stuff together it would still be good if it all had the same material/shader
    -dont use alpha ! seriously 99% of the stuff people use alpha for these days could be done with actual geometry and it would both look better and perform better !
    -use as little transparent stuff as possible ... if transparency cant be avoided (fire for example) make sure it covers as little screen space real estate as possible and doesnt come in multiple layers ... special tip for fx artists: 1 sprite with an animated texture will usually look more awesome than 10 layered sprites with a static texture ! and it will perform better too win/win scenario !
    -i think this will become less and less relevant but try to have as few hard edges(smoothing groups) and uv-cuts as possible in your model the less split verts the better transform time (but your game is probably not transform bound anyway)
    -the thing above + clean poly flow will ensure better triangle strip generation ! which saves memory and transform time ! yes sometimes MORE geometry can result in less memory use and less performance loss if done right !
    -transform time for verts on skinned meshes(characters) is more costly than that of static world geometry so dont apply your optimization knowledge on how many polys to spend from envs on characters !

    i am framerate nazi ... there you have it !
  • Eric Chadwick
    Heh, what did I say? I think I kinda just punted there.

    warby's advice though is spot-on, that's a very solid review of framerate-speedup solutions! Nice one man. And everyone is fillrate bound these days, so these techniques are important for all to learn.
  • Eric Chadwick
    Added to the wiki here, last link down at the bottom...
    http://wiki.polycount.com/PolygonCount#Articles_About_Performance

    warby, for the attribution I grabbed your full name from your site, but if you'd like something different that would be fine too, just PM me.
  • Mark Dygert
    I quoted you as saying "talk to your graphics programmer". Talk to them early and often, if I remember correctly the last time you said it. Probably schedule time to talk so you're not constantly pulling them off task.

    Most do this weird thing where their eyes roll back in their head, they talk a funny language spitting out numbers and then slowly start making sense again as they translate into artist-ese. Considering most of what gets posted here on polycount is an artists translation of those conversations, it's better to go straight to the source. If you can't, it helps to deal in as much 2nd-3rd person info as you can but sometimes it starts to get confusing because not all games are the same and not all priorities are the same even within the same game.
  • Mark Dygert
    One more thing to keep in mind is that it can be best to stick to a standard texture size. Most people understand this as a rule but don't understand the logic behind it. The way I understand it is that its easier to load and unload blocks of textures if they're the same size. Unless your using id tech5 which compiles all of your separate textures into one giant texture atlas. However this is largely automated from what I understand and artists still interact with textures and objects roughly as they always have but maybe bundleling things up more often than they normally would.

    For the rest of the engines its generally a good idea to stick to standard texture sizes, the reasoning being its faster to have the engine do:
    "Replace a texture that's not being used, with this new one"
    Than it is to do:
    "Find textures that aren't being used, find one that matches this size and replace it with this new one"
    Or:
    "Put this tiny 32 texture in this big 1024 slot (wasted space) so we can swap slots easily."

    So a 512 or a 1024 for everything? What about textel density? Won't that lead to a pop can having way too many pixels and a cliff face having not enough?
    Yes, but thats when you do like Warby suggested and bundle smaller objects together, so long as they will be placed in the same area and you won't be making a giant call for those few pixels tiny pop can uses.

    Ok so bundle everything into one giant atlas?
    If you're using id tech5 yes, if not then other games optimize differently and probably make better use of smaller uniformly created texture sheets like 1024 texture blocks.

    Also keep in mind if you're creating props for a single player game you're more likely to bundle objects into mini texture atlases. Typically you just pass a note onto the people placing the props, "place these together". If you're creating props that will be used by end users to create their own content like multi-player maps for TF2 then you might want to separate the sheets because there is a good chance those people will use the props in unexpected ways. Like placing one of those props and not the others, which puts in a big draw call (I think I'm using that term correctly?) and only uses a tiny part of it. If that happens enough times with enough objects from all over it can slow things down and clog up the GPU more than just using smaller atlases.

    Normally you want to hold to a textel ratio on objects. So the textels in a game are all the same size so you don't have tiny sharply detailed objects sitting next to horribly blurred giant object. A common ratio is 4:1, 4 textels to 1 game unit. If you have a plane that is 32 game units then you need 4 times the pixels to texture it, 128x128px.

    Holding to that you start to figure out the different texture sizes based on the surface area they have. If you have a cube that is 32 x 32 x 32, then you have 6 planes that need 128x128px (if its all to be 100% unique) 768 that's a wonky size and not a power of 2. The nearest power of 2 texture sizes are 512 and 1024 and 6 planes don't pack into a square easily so you're going to have dead space either way.

    So to get 6 sides to fit into a square you can stack 2 of the sides so it fits into a square easily and that takes it down to 256x256px.
    Box_Unwrap.jpg
  • fearian
    Offline / Send Message
    fearian greentooth
    This is really interesting. I'm having a bit of an internal crisis with myself over a modular building I'm creating: I have modular building pieces (walls, windows, shot fronts, canopy's) all sharing one giant 2048 texture. The modular pieces are not one model - each one is a mesh in UDK that I can move it around. however because their individual UV's end up taking up only a small space of the texture, I end up having to give each mesh a huge lightmap to compensate, killing my lighting build time.

    Is it worth keeping the textures for these meshes on the same sheet? or should I just give it up and give them their own separate texture space?

    Sorry that may be a confusing explanation without any pics :B
  • m4dcow
    Offline / Send Message
    m4dcow interpolator
    fearian wrote: »
    This is really interesting. I'm having a bit of an internal crisis with myself over a modular building I'm creating: I have modular building pieces (walls, windows, shot fronts, canopy's) all sharing one giant 2048 texture. The modular pieces are not one model - each one is a mesh in UDK that I can move it around. however because their individual UV's end up taking up only a small space of the texture, I end up having to give each mesh a huge lightmap to compensate, killing my lighting build time.

    Is it worth keeping the textures for these meshes on the same sheet? or should I just give it up and give them their own separate texture space?

    Sorry that may be a confusing explanation without any pics :B

    Are you making a second UV channel that has the UVs for these meshes maximized?
  • fearian
    Offline / Send Message
    fearian greentooth
    Do you mean for lightmaps? yes, but again, they are all on the same texture, and with less overlaps, so space is tight.
  • Eric Chadwick
    Usually the best bet for modular building pieces is to use the modularity to put together your bldgs in your DCC app (Max, Maya, etc.) but then attach all the pieces of one bldg into a single entity. Then, create your lightmap UVs. That's generally the best way, though I would look closely at how Epic does it if you're working with UDK.

    Keeping them separate pieces works well if your engine handles instancing/batching well, so that all the instances of one modular piece are rendered at once (a batch) rather than one by one. The thing to avoid though is that your modular pieces may be in distant parts of the level, which doesn't help when batching... batching is for things that are all being rendered at the same time (or nearly so, if the engine caches things for a little while).
  • warby
    Offline / Send Message
    warby polycounter lvl 18
    @fearian what you should do in these cases:

    scenario a) i want to reuse and recombine these meshes 1000 times in awesome cool new ways

    than do this: keep all those meshes separate (same atlas map/material though) but make a second uv set for each one of them that covers the full 0-1 uv range !

    scenario b) these models have a specific way how they stack ! the first floor will always be above the shops in this way and it cant be used in any other way!

    than do this : merge em together in your 3d app export em together as one mesh and once again make a second uv set that covers the entire 0-1 space but you know all of them together this time !
Sign In or Register to comment.