Off Topic

Promotion
Once-per-game feedback requests or release threads are OK, but a considerable history of participation on /r/gamedev is required. Must be a Text Post.

Devlogs that do not have a focus on being useful to other developers. Do not talk about what advancements occurred on your game this week. That is what Feedback Friday, Screenshot Saturday, the Daily Discussion thread, /r/devblogs, and /r/gamedevscreens are for.

Memes

Explicitly On Topic

AMAs
If you have a unique perspective on something, we'd love to hear it. This is not a way to promote your game/kickstarter/etc, please see above. The focus should be on providing info to the community, not promoting yourself. Be sure to include your education and years of experience to provide some context.

Restrictions

Do not use [tags], assign flair to your post after it's created.

Question posts...
should include what you've already tried and why it was inadequate. Be sure to check the FAQ.

Learning Sketchup and Blender, making textures and wrapping my head around unwrapping and generating normal maps, and so far it's mostly ok.

However, I'm a professional photographer and retoucher, and working with some aspects of texturing is a total mindfuck. I'm used to dealing with massive files (200mb+) and still being unhappy with the effective printed resolution.

Anyone have any tips to understanding working with crazy tiny files for someone used to working in a 300dpi world?

Should my textures be sharp or blurry?

If I'm making a model, say a sword, in an FPS, what size should my textures be?

If I have a textured cube with a 512x512 texture, and it gets very close to the camera at a decent (1080+) resolution, won't it look like a blurry piece of crap? Shouldn't that really be avoided?

Sure, ideally you could get in as close as you want and have all the detail in the world. But we have to deal with technical limitations. I was working with a 4kB texture cache on the N64: that is, 4096 bytes, or typically a 32x48 texture (for mipmapped and rgba5551). It was still possible to get texture resolution to roughly match screen resolution 1:1, by careful camera framing and judicious use of texture tricks, and also due to the low-res screen. The world was textured with 16 texels/meter.

In a situation of a completely free view you have to accept that a player can get up very close to objects, and will also be seeing them from as far as possible. But there will be a region (distance) where you want to optimize clarity -- textures there should be at their sharpest, and so, ideally close to 1:1 with the screen. Having super-high-res textures beyond what the display can resolve just means you're mostly seeing muddier mipmaps (downsampled blends of your original texture).

You can develop some guidelines. Make a wall of textured cubes in your world, all at different texture resolutions, but the same cube size. You can move around and see how the different resolutions look at different distances. Consider what depth you expect to be of greatest interest in your game. You'll probably find that a resolution which matches screen looks best (let's say eight 1m cubes fit across the screen at your ideal distance, and you're targeting "Full HD": 1920 pixels across. Then you know each cube is (1920/8cubes =) 240 pixels at that distance -- so 256 texels per meter might look great). Try to see whether the highest resolutions actually look worse at that distance -- to convince yourself that "bigger isn't always better" -- we're dealing with tradeoffs. Still, you might feel the need for increased resolution because near objects are common. That's fine -- it's all about establishing what works best, and giving yourself some concrete measures will help you determine what "best" means.

You can also use a technique of "detail textures" to add a crunchy, noisy layer of detail to textures for when they are magnified -- this helps give a sense of detail to something which would otherwise be blurry. Similar to how leaving high-ISO noise in a photo can be better for a sense of detail even though it's noisy.

Another point... what you want more than color-texture at high resolution is normal maps. Color can be pretty rough when you rely on normal-maps for detail. Although normal maps are even more sensitive to downsampling (high-res viewed at distance).

Edit: Additional note...

Since I don't like to have my scene living entirely in the murky depths of mipmapping, here's something you can do to visualize it (if you have access to mipmap generation): Generate each mipmap level as a pure color: red for full res, green for the next step down, blue, yellow, cyan, magenta... that should be enough. It's really handy if you can let the engine toggle a rendering mode like this. What you will see is a colored mapping of what mipmap levels everything is in... near-and-facing-you will be red, but distant or oblique might quickly drop down to cyan and magenta. If you don't really see any red (level 0, full res), then you're wasting texture bandwidth and storage and looking at lower quality mipmaps everywhere. If you don't have uniform texture detail (for example, some small objects are wrapped by 2048x2048 maps, and some larger ones have 512 stretched across), these differences will really show up -- this is where it can be handy to toggle, so you can flip back to normal render and see which textures might be worth investigating.

It doesn't make sense because you are leaving out a new, important constraint that you did not need to think about when doing print design: memory budget. The goal is not to make everything in the game look sharp at all resolutions. The goal is to make everything look as good as possible while using less than a pre-specified number of texels.

For example: Let's say you are using DXT5 texture compression (1 byte per texel) and have a texture budget of 133 megs for a given scene (small for PC, big for mobile). That's enough for 100 1K x 1K textures (100x1.333 to include mipmaps). But, is 100 1Ks really the best way to spend your 133 meg budget? You can trade one 1K for four 512s or sixteen 256s. Or, you can trade-in four 1Ks for a single 2K texture. What is the best allocation depends entirely on how visible each texture is on the screen.

Ideally, there would be > 0.5 texels per screen pixel. Given that you only see half of a model at any given time (the screen-facing half), you would need a 2K texture to achieve that with a 2K display in the case of the model filling the entire screen. But, is every model really going to fill the entire screen in practice? If it's rarely larger than 200 pixels on-screen then a 256 is plenty. A single 2K is worth 64 variations of 256x256 textures. Having 64 different textures that look fine most of the time can make the game look tons better than have 1 that still looks perfect when you press your nose against it.

Textures should be as sharp or blurry as they need to be. They should also be as big or small as they need to be. What you should consider more than anything else is how the player will interact with the object.

If this is going to be an FPS weapon, it's going to be right in front of the player's face all the time. It should be lovingly detailed all over, because the player will see it for a long time, and because it's going to take up enough screen space for the detail to show. By contrast, a chair doesn't need anywhere near as much detail. The player is going to walk past it without really scrutinizing it, and it's going to spend nearly all of its time as a tiny, tiny bit of the screen.

To put this in photo terms, imagine you're doing a composite. Your subject that's going to take up the major part of focus and area in the composition needs to be the biggest, loveliest resolution you can get it. However, it's not really important that the children you can see playing out the window way on the horizon have that resolution, as they'll be tiny, indistinct, and largely unnoticeable. In this case, you also have to deal with the fact that the tiny, indistinct children are a drain on system resources, sou you only want to give them as much detail as will be visible in the final scene, or else you're wasting processing power.

I generally prefer, for flexibility's sake, to start with 2048x2048 resolution for a major prop and 1024x1024 for a minor prop (bear in mind that 2048 is more pixels than the width of the vast majority of monitors when thinking about the scale here). Starting at a higher resolution allows you to finish it with sufficient resolution, then shrink it as much as you can get away with. When resizing for textures, subtle sharpen filters are your best friend.

If this is going to be an FPS weapon, it's going to be right in front of the player's face all the time. It should be lovingly detailed all over, because the player will see it for a long time, and because it's going to take up enough screen space for the detail to show.

It seems like most FPS games have separate "firstperson" and "world" models for their guns, so the gun carried by the player has lots of texels and lots of triangles, and maybe an ammo counter and some complex animations, and the guns carried and dropped by enemies are less animated, don't have ammo counters, and have just a few triangles and texels by comparison.

At the photo-real end of the spectrum, if the cube has a face parallel to the screen, and has its top and bottom edges neatly matched with the screen, so that the displayed polygon is 1080x1080 pixels, then you will need at least a resolution of 3240x3240, as most 3D renderers are capable of sub-pixel accurate rendering. If you've got a common or garden LCD screen, then you have 3 subpixels.

Multisampling can push this number higher. There's Nyquist Sampling Theory hiding around the place, but I am not smart enough to explain it to you. Suffice to say you can push more image through a screen than the simple resolution would have you believe.

Having said that, computers aren't fast enough to throw around real-time photo realistic graphics, so we have to settle for lower resolutions.

If I'm making a model, say a sword, in an FPS, what size should my textures be?

This is a decision that your programmer will make, or if you're in a bigger shop, your technical director. They will decide based on the performance of their engine/hardware, how many assets they expect the engine to push around at once, etc.

Shouldn't that really be avoided?

Yes, but gamedev is all about these sorts of trade-offs.

Anyone have any tips to understanding working with crazy tiny files for someone used to working in a 300dpi world?

Don't change a thing. You're already doing it right. Typically folks will work at your crazy resolutions, and down-scale the final thing, and tweak the exact resolution to try to get the best performance/visual quality trade off. Just remember that this work will eventually be 50x50 pixels, even though I'm currently working at 4k, so don't bother with features smaller than 2% of the image size.

Oh, and 512x512 is thrown around because it was the maximum supported texture resolution of the 3Dfx Voodoo1. Modern cards will happily throw around 4K textures, last time I checked my videocard supported 16K textures. You're only limited by the hardware.

Historically subpixel accurate rendering is nothing to do with that although it is related as a general-use term of course.

It just means that you can use a coordinate system that does not end up mapping 1:1 with pixels on the screen.

There was a time before 3d cards where software rendered 3d engines would transform a triangle from 3d to 2d space and then send the result to be drawn via 2d integer screen coordinates. This was fine for jerky player motion and still looked ok.

But once things became smoother, especially when the mouse came in as a control method it was obvious that triangles being locked to pixel boundaries was a terrible idea as triangles and textures warped and shimmered around when moving at extremely slow speeds. And so the polygon drawing code was changed to being done as fixed point screen space coordinates rather than straight integers. Nowdays it is doubles/floats of course as the hardware can handle it but the result is still that we can specify things to be drawn at an accuracy greater than individual pixels. The other huge bonus that we gain from it is being able to use a fixed virtual 2d screen resolution and have it scale correctly to the actual resolution. The aspect ratio is the only bit left to worry about.

That paper is about (if my quick skim of it is right) using increased resolution in depth/normal buffers to do a kind of super-sampling without increasing the pixel shader cost. It uses the term subpixel, but is not the same thing as subpixel accurate rendering.

Texture sizes don't exactly correspond to screen sizes unless the texture is laying at 0 depth like a menu item. The only other thing I'd point out is you'll need large textures and/or good tiling and blending of multiple textures on largely scaled objects; there is likely some math to work this out but sometimes you are constrained by memory and must do your best aesthetically. It really depends on how far back the view is compared to how high a res you're looking for within reason. Not an answer really, but worth some thought at the same time.

If I have a textured cube with a 512x512 texture, and it gets very close to the camera at a decent (1080+) resolution, won't it look like a blurry piece of crap? Shouldn't that really be avoided?

Sometimes it depends on the texture. If you have something with softer details like a gradient, water, or something blurry you can get away with low res.

World of Goo's depth of field effect masks the fact that the background and far foreground elements are lower resolution than the midground level graphics.

Also if you want more detail on a surface when you get closer without having super high res textures, you can use detail textures. Instead of having one very large high-res texture, you have two moderate-sized textures, one that tiles less often (base) and one that tiles very often (detail). As an example, get up close to the test chamber walls in Portal 2. There are little circular divots that are the result of a detail texture.