View Full Version : Pixel/Texel Density theory
01-06-2005, 12:47 AM
I'm sure that this is more than likely a known thang' to most of you enviornment artists out there, but I'm reletively new to scene building.
This all came to mind after working with the Halflife2 SDK, and seeing the way they created their textures. If you break it all down, there is a very simple system they used, which makes all the textures look great in-game. In the Hammer editor, each unit is equal to 1inch of world space. A wall for example, is supposed to be 128units tall, 128 units wide. If you divide that by one foot (12units), you get 10.6 feet. For that area of space, they use a 512x512 texture. If you then take 512 (texture size) and divide it by 10.6 (feet), you get 48.3 (round down to 48). The value of 48 is the pixels-per-foot of world space. This breaks down their pixel resolution to 4 pixels-per-inch of world space.
From here, I took it further down, into the console world. I figured, Xbox should get 1/2 that resolution, and PS2 should get 1/2 of that. So for a 10ft square area, the PC gets a 512x512, Xbox gets a 256x256, and PS2 gets 128x128. After applying this to simple holding textures (based on Valve's "orange maps"), I found that everything looked amazing in-game, and mip-maps were working perfect. Even on PS2, there was no need to tweak to the auto-generated mipmaps. You can still create texture pages as well, as long as your pixel-per-inch ratio remains the same to it's world space counter part.
It's entirely possible that I'm reading too much into this, but it surely works, and damn well. If this is something you guys all know, please slap me around a bit. I'm stuck in the unfortuneate position of NOT having an experienced person to learn from at work, particularly with consoles. In fact, I'm the soul enviornment artist at our studio. So when I think up a theory like this (which sounds so simple), I feel like I've done something great; when in fact, it's standard knowledge.
Thoughts? Foul language? Let it rip.
I'm going to sleep. /images/graemlins/tongue.gif
01-06-2005, 11:13 AM
Are you just talking about using a consistent pixel-to-foot/meter ratio across the board when creating textures for games? My first experience with this was my first industry gig (UX:O). Now it drives me absolutely nuts when a client doesn't use a pixel-to-foot rule for objects/environments. Things look so much more consistent when you use consistent texel scale on a project.
01-06-2005, 12:57 PM
Exactly, Zombie. I figured it was common knowledge. But like I said, I have no one to learn from here.
And yes, this is all about using a consistent texel scale. I agree that things just look BAD without some general rule.
01-06-2005, 01:32 PM
Back when Pulse3D used to be around (a web 3D engine), they had a tool that massaged all tiled UVs to use the same texel density. Not sure if it was all that useful, never had a chance to use it myself. Might be helpful though for something like lightmap UVs.
01-06-2005, 04:19 PM
This is definetly something every texture artist should keep in mind. Although all the math might scare off some artists. With the HL2 example, if you just keep in mind that a 128x128 unit poly square uses a 512x512 texture, then you can just go off of that for all the textures. So a 64x64 piece of geometry would take a 256x256 texture, or a 256x256 piece of geo can take a 512x512 texture tiled twice horizontally and vertically.
I find that if I try and keep all buildings modeled using 128x128 squares as a base, for example, or some multiple of that number, then it's easy to know what size the textures need to be or how much they need to tile to keep a consistent texture density.
01-06-2005, 06:03 PM
I actually have checkered texture maps in different sizes (512x512,256x256, etc) that I use for consistent texel scale. Then I set up the grid in max so that one check = one grid space. Really easy once you get your max grid set.
01-07-2005, 10:31 AM
Or just eyeball it like the rest of the world /images/graemlins/smile.gif As long as it visually looks the same, it's good.
01-07-2005, 03:56 PM
It's not a hard rule. Look at the textures on the top of some of the buildings in HL2, they're extremely low-res, but since you can't get within 50 feet of them, it works. Also, the first person weapon models probably have a higher texel density than the rest of the world.
01-07-2005, 04:30 PM
Although its a good idea to keep pixel density in mind, some games benefit from deviating from an even distribution of pixel density. In games where you get fairly close to characters faces, having somewhat higher-res textures on heads works nicely. Or if large objects are never/seldom seen close up (e.g. upper parts of outdoor buildings), they don't need the same pixel density. Having an in-house tool/special texture map that indicates when objects are using MIP maps can help...if your object is always using its MIP map textures, the texture should be reduced in size.
EDIT:I Just scrolled down and read Doc_Rob's post, which says the same thing...
01-07-2005, 06:02 PM
I guess this will be the second thing ill need to learn when it comes to my enviroment artist education right?.
Its common sense stuff really,the further soemthign away is less detail needs to go in to it,but for me as fat has alraedy pointed out,mathamtical failures like msyelf might struggle with working these out,vassago any chance of a summary or tutorial or soemthing to help put this into a simple format for noobs like msyelf /images/graemlins/smile.gif.
01-07-2005, 06:09 PM
It really all comes down to how it looks in the game engine and how it affects frame rate. You would never blindly follow any rule or calculations.
If you're just starting out, go buy yourself a copy of Half Life 2 or UT2004 and start making levels. After a while you kind of get a feel, or more accurately, an eye, for what works and what doesn't, or what you can get away with and what you can't. There's always a tradeoff between looks and performance, so you have to find where the happy medium is and go from there.
01-09-2005, 01:57 PM
The rule of thumb I follow is that if it looks good move on to something else, there is no way to have a set of rules that work all the time unless you work on the same game engine and same game type for the rest of your life. Example, the last game I worked on we had a somewhat fixed camera and no mip mapping support so having the same density of textures in the background caused flickering and moire, so we put all the texture budget into the key objects in the foreground and used the lower res textures for the background object, as well there are plenty of models with texture stretching in the environment and sometimes this is actually a benefit as some models really don't require perfect uv's to look good in game, also I found that creating textures at square proportions and then scaling to rectangle freed up a lot of texture space with no visual quality change in game. I primarily work on ps2 games so we have to be extremely prudent about our texture budgets as we were only allowed 1.2meg of 8bit compressed textures for the entire environment on our last project. That's not very much compared to a geForce6800 with 256meg of texture ram, although I'm sure the guys at Valve had limitations to work with as well. So like I said, as a rule of thumb if it looks good and it fits within your budget then I really wouldn't worry about making sure every single pixel is square in your uv's, you might get really frustrated trying to sort this all out for every face of the models.
01-12-2005, 12:26 AM
Well yea for sure, no mip maps will throw the whole thing out the window there.
I've had bad experiences with the texture-squashing thing, so I try to aviod it where possible. For PS2, I find myself using a lot of desaturated palettes, and 4bit textures. Suprisingly, most things look good in 4bit /images/graemlins/wink.gif
01-13-2005, 09:09 PM
This theory kinda goes out the window when you start dealing with anything other than BSP surfaces. After a certain point, pixel density is meaningless and trying to arbitrarily enforce a global standard is a waste of time and energy. If it looks good and runs good, go with it.
vBulletin® v3.8.4, Copyright ©2000-2013, Jelsoft Enterprises Ltd.