Figured a couple of you guys might be able to toss some pennies on the table here.
I'm currently planning out some technical back-end shit for an environment project that'll use UDK (surprising, I know). The set up will be for a street level environment, urban, third or first person.
Going off this thread
here, I've come up with the image below. The two buildings are just sample ideas for 'types' of buildings.
Working within a given metric will never yield perfect world results, some scaling is bound to be off but I wanted to run this past you guys and see what you all thought.
Since I am using UDK, however, I am assuming player height is locked at 90u if I want to simply drop in and run around so I am working off that.
So... thoughts? Look about right?
I'll be updating the image below as I go along.
Replies
It would probably be better to do a mockup and see how it feels.
Many aspects of architecture are tweaked for the purpose of flow and camera angle. You say third/first person, just make sure you know how far the camera will be in third person (and I assume it's the standard cam for first person). Hallways, doorways, rooms/ceilings, spacing of pillars, are a few that I can think of where scale would be essential.
Taking for instance GTA 4, their doors and halls are a lot bigger and wide to make up for the slightly goofy movement of the player (primarily when turning). On the other hand, Half-Life 2 doors and halls were a bit more realistic, narrow and more confined, making close combat a bit dangerous.
As a preference, I'll tend to work in units of 16 in max (setting up the grid thusly). But anyways, there's some pennies.
Anyway, I lost the files because I am a smart, smart person.
72 unit characters (6ft, 1.8m)
128 unit wall tiles (10ft, 3.25m)
96 unit tall door ways (8ft, 2.5m)
If you use 4pixels for every game unit you cover the 128 unit tile, that works out to be a 512px map. But in unreal you have to beef everything up because they beefed up the default camera height to 96 units.
I think when they originally had unreal characters they where roughly 6ft tall, but over time they grew to give you a sense that you where bigger and bulkier like a space marine, compared to puny human height (if the rest of the world was to scale). That makes things a little harder if you want to be real world relative to a hulking camera... so you end up kind of adjusting everything up 24 units?
That's just my observations based on my latest project that required me to be a bit more precise. I haven't done too many closed indoor environment in UDK before so take this all with a grain of salt. If it make sense and works for you, great roll with it. If not, forget it
1uu = 1cm, then just run a pixel density of 256px per meter.
I usually stick it as an automatically executed console command in kismet (along with the FOV change), when I realise I'm not satisfied with the scale of a scene and I'm too far in to scale everything.
Obviously I guess it's better to work at the right scale, but for a personal project it's probably not so important if you're staying in first person view.
If it works, it works.
2.56px per 1cm seems kind of low and hard to calculate, its not going to land you on a power of 2 as often as using 2px per 1cm OR 4px per 1cm
128uu x 2.56tx = 327.68px (256 or 512?)
128uu x 4tx = 512px (512 it is)
It seems like going a bit bigger(4:1) and scaling down if necessary is better than trying to up res smaller texture sheets(2.56:1)?
1m, 2m, 3m instead of 64, 128, etc.
So 100cm/100uu = 256px
Keep this discussion going, as I still haven't decided where I'll land. I need to get back to my PSD file to write all this down.
In-game: 128uu = 512px
Authored: 128uu = 1024px
1uu = 1cm
4px : 1cm/uu (authored at 8px)
Switching to metric makes a lot of sense. I'm rolling with this unless someone comes up with something better. I have some re-engineering of my scene to work out... damn you lunch break for being over! I really want to mess around with this now =P
For the Source side: When I see the height of the player next to the wall, then think that wall is going to have a 512x512 on it, all I can think of is how blurry it'll be (source does have a fairly low res compared to the standard today).
So, I'm not sure 4px = 1uu = 1cm is the right way to go, but rather 8px = 1uu = 1cm.
128uu/cm @ 1024px...
With 8:1 you just need to be mindful of the dreaded down resing (at least in production). Don't draw 1px lines or use tiny fonts on a larger sheet that might be cut down latter bla bla bla... crap you already know and probably told me at some point hahaha.
@ nfrrtycmplx I think you need to make sure your grid in max/maya/whatever matches the UDK grid.
So your grid works in MULTIPLES of whatever the UDK grid is set to.
For example your grid will have lines every 8cm or 16cm to match UDK.
Which is different than POWERS of 2 where the higher you go the larger the leaps (256, 512, 1024, 2048, 4096 ...) instead of working in incremental distances (8, 16, 24, 32, 40 48, 56, 64 ...)
Luckily they have "1" on the grid so you can snap to odd numbers but on a very small scale so its also easy to fudge up unless you're zoomed in all the time. It seems like 8-16cm/uu are a good default grid spacing for both grids, what matters is that they match.
To set your grid in max:
Right click one of the snaps buttons and modify the "home grid" to be 8, 16, 32 whatever works best in UDK for your project.
TL:DR
Metric makes sense, 1uu = 1cm = 4-8px per 1uu
Sync your grid to UDK, 8 or 16
Grid objects can be found on the Create Panel > Helpers Tab, or Main Menu > Create > Helpers > Grid.
The only down side is one grid object can be active at one time, select grid object right click > activate grid/activate home grid > or bind it to a key.
I went into home grids and snaps in a bit more detail here:
http://www.polycount.com/forum/showthread.php?p=1098044#post1098044
They've made working with snaps A LOT easier and more precise since I wrote that up, 2010 and lower you're stuck with the old snap system I complained about, which can be frustrating to use when you need precision.