IMPORTANT : keep in mind that this article aims to discuss 'normal' and 'parallax' maps in relation to game engines, which may not implement the actual technology fully or use terminology that's not 100% technically correct - for instance, 'proper' parallax maps (i.e. that conform to technical papers on the subject) do something called 'self occlusion' - amongst other things - which Oblivion's parallax maps do not do. For more information on this search the Internet for technical papers covering the subject.
Aside from the pixel and vertex programs used by the game engine to render textures to screen, generally speaking, nothing. Here's why.
A normal or parallax map can be produce in one of two ways; by rendering out a high resolution 3D model to 2D or by converting flat 2D artwork into a normal map by using a 3rd party program or photo editing 'filter'. Both methods of production result in a 'normalised' image, similar to the ones shown below, an image that will 'displace' on screen pixels in such a way as to create the visual illusion of surface depth in a game.
The image on the left is a normal map from Oblivion; the one on the right, for use in Quake 4
As you can see in the images above, there's no significant difference between a normal map used in Oblivion (the one to the left) to one used in Quake 4 (the one to the right); both games - Oblivion's parallax mapping and Quake 4's normal mapping (i.e., the actual process or system of rendering, or 'mapping' images to the virtual world) physically use the same type of "normal map" image as part of their respective rendering process.
Oblivion uses standard normal maps as part of its parallax 'mapping' process.
What this means is that the actual process, parallax 'mapping', is not the same as parallax 'maps', the two are different - Oblivion doesn't actually use parallax 'maps' but it does use parallax 'mapping'. How about that for confusion. In effect, you could use a normal map of a brick wall in any game that supports normal maps; the only significant 'feature' that currently matters is the orientation of the RGB channels as they dictate whether the bricks of the wall stick out or recede back.
Normal(ised) maps are baked, rendered or converted 2D images used to represent ('fake') 3D depth on flat surfaces in games and interactive 3D.
Design note : normal maps can in fact be generated from baking 3D models out to 2D normal map, or, by the appropriate conversion of a 2D source image into a 2D normal map using a photo editor plug-in/filter or standalone normal map program.
This is done by making use of the 'red', 'green' and 'blue' channels present in a standard 2D image with a 24 bit colour depth (colour 'palette') as a way to store 'directional' or 'special' data relative to 3D object depth; in other words, the 3 dimensional depth of a brick wall can be represented and interpreted by the use of colour instead of actual modeled polygons in game. These channels or layers can be individually inspected and edited using a photo editing application like Photoshop or GIMP.
The normal map used on the a Ayleid Ruins wall model, the texture from Oblivion shows each of the Red, Green and Blue channels combined ('RGB') and as separate single colour objects ('R', 'G' and 'B')
What you're technically seeing when you do look at each channel like this is an individual layer that has an 8 bit colour depth; each one contains 256 tones of just a single colour - 256 tones of either red, green or blue. Or to put it another way, how much of each individual colour is being used to produce the combined colour of the original image; view the channels together and you get the original image; separate them and you get each of the R, G, and B colour components.
Design note : multiply each 256 channel by each channel and you get the 16 million colours your monitor's 24/32 bit colour depth is capable of seeing (256x256x256).
Because each R, G and B channel is 8 bit - which gives a 'colour' or 'tonal' depth of 256 shades per channel - it means an RGB image has, in total, a colour depth of 24 bit; this gives us a standard image used in pretty much every game available. However, it goes one step further; another 8 bit channel called the alpha channel can be added to our 24 bit RGB image to give us what is then a 32 bit RGBA image.
Red
Green
Blue
Alpha
Design note : It's important to understand here that even though we're talking about a "32 bit" image, it's not technically a 'true' 32 bit image; we're still physically dealing with a 24 bit RGB colour depth image that just has an additional channel added - 24 bit + 8 bit totaling 32 bit. A true 32 bit colour depth image uses a CMYK colour palette (Cyan, Magenta, Yellow and Black) as is common for printed material, and is capable of reproducing a tonal range of 4 billion (?) 'colours'.
The introduction of another channel, the alpha channel, brings the image to 32 bit
This 'A' or 'alpha' channel tends to be reserved for the use as a 'mask' or 'alpha' channel - typically containing objects that effect the appearance of the base RGB channels by removing parts of the texture or blending them together with other images to create additional effects in game.
The alpha channel doesn't directly effect the colour of an image by it's presence; unlike the other channels, you can turn it 'on' or 'off' and the base image will remain unchanged.
Simply for the following reason;
Each of the RGB colour channels represents an axis of orientation
If you imagine the corner of a box, as you look at that corner you'll notice three cardinal 'axis' which gather or terminate at the very tip of the corner itself, typically;
Left-right ('X' axis)
Front-back ('Y' axis)
Top-bottom ('Z' axis)
Red, Green and Blue channels respectively. Note the direction the 'lighting' (shadows / highlights) appears to be coming from and how that effects what you see.
Now depending on how the game engine is set up, one colour will represent one axis of either 'X', 'Y' or 'Z' - 'blue' for instance, might be coded to represent 'height', so the more blue present in the channel the greater the depth / height being represented, interpreted and then rendered to screen ('blue' usually is 'depth / height' by the way).
Design note : Now the problem here is that different programs, whether 3D or 2D, tend to use different cardinal axis orientations; what may be 'up' ('Z') in 3DS Max may be 'left-right' ('X') in nVidia's Photoshop plug on filter; they don't all always adhere to the same use of the standards associated with normal maps.
The results of this are often textures that appears inverted (upside down) or they display shadows when it should be showing highlights. Fortunately, it's relatively easy to fix.
You may have noticed the alpha channel isn't mentioned here, that's because, as was mentioned above, we're dealing with an image's physical colour depth; alpha channels have nothing to do with describing the actual colour palette of an image, they act purely as 'masks'.
This depends on the game. Although normal maps have 4 channels available for use; Red, Green, Blue (X, Y, Z) and Alpha, some games tend to use just two of them; the Red and Green ('X' and 'Y') channels (the alpha channel often used as a mask or filter to blend or remove image sections). This means the Blue channel ('Z') may not get used (partially or wholly); if we look back to the information above we find that this is the channel that often corresponds to 'depth / height' ('slope').
So instead of using the blue channel what's done in these instances is to make use of a separate 24 bit gray scale (black to white toned) image which provides a more detailed 'height' (bump) map; it 'replaces' the information that would otherwise be contained in and subsequently read from an images blue channel. This height maps is then combined back in game with the normal map using any extra settings that might be added via the interpretation of 'shaders' (extra calculated depth for instance).
Design note : There are several advantages to doing this;
Better control over how the combined textures looks in game - textures can be easily tweaked with just a line or two of text rather than having to reedit the original source files.
Tonal gray scale' range increases which allows greater 'macro' detail to be shown, especially at the higher texture resolutions. This is due to the separate height map image actually being in 24 bit (RxGxB - 8x8x8 bit) rather than just a single 8 bit colour image; in a 24 bit image each 8 bit channel has 256 shades of gray (in the case of a height map) so when you add them all together you get greater and greater tonal detail and colour range, even with a pure gray scale tonal range.
Very few games actually utilise normal maps in this way now, preferring instead to simply make use of the full range of available channels contained in an image for in game surface texture rendering. This is how Oblivion uses normal maps, it utilise the blue channel.
Design note : It's important to note here that although other normal mapped games may not use the blue channel, as mentioned above, the channel itself may actually have 'data' in it; this basically means the data is generally being ignored (not used) by other game engines and renderers; the blue channel is rarely completely 'blank' (contains no data other than a flat uniform blue).
Because Oblivion is using the blue channel it means it won't ignore the data it finds there; it's part of what Oblivion uses for the games 'parallax mapping' - the other part being the alpha channel of the diffuse image, along side the math involved, it's where the method gets it's height information from (as opposed to a separate gray scale images as mentioned above).
To stress the point made in the first paragraph of this tutorial, the main 'thing' to remember here is that normal maps as used for Oblivion's parallax mapping system are exactly the same as normal maps used for other games, there's no difference between the two.
Take a look at the two images below, the one on the left shows the blue channel of a wall texture used in Oblivion (textures\dungeons\fortruins\rf1xarchunder_n.tga), the one on the right is the blue channel from a custom texture used in Quake 4; they're approximately the same 'technically', i.e. how the data is arranged relative to the objects they're trying to 'describe' - obviously there are positional differences because each is a channel from completely different texture of completely different objects.
Left; blue channel of a texture from Oblivion. Right; blue channel of a texture used in Quake 4
What this means for modders wanting to create custom textures is the following; so long as you're producing a standard normal map using whatever tools you have available, you shouldn't need to do anything else to the image. It really is that simple. In fact, unpack the texture assets and go through some of them, you'll find them all to have blue channels that look approximately the same as the images above.
Technically yes, but what you can do is limited in a number of ways, least of which is whether your photo editing software is will allow it; Adobe Elements for example has channels disabled so you can't view them let alone edit them. However, and this is important, if you're editing the channel attempting to paste in a height 'booster' you'll most likely find that not working the way you expected it to.
As was mentioned in the section above, the data that's actually contained in the Blue channel is relative to the information of the other two, essentially this means if you edit one, you should really edit the others so that everything is balanced. By dropping in a 'booster' or editing the blue channel in isolation you may very well end up unbalancing the fundamental relationship between all the channels, the resulting image may look and behave incorrectly.
What this means is that if you're wanting to edit the normal map you should generally speaking be doing it in normal edit mode (full colour RGB), that way all the channels remain balanced with each other (you can edit in single channel mode but you have to remember to edit the other channels in relation to the changes made).
So now we know what normal maps are that Oblivion actually uses then in the same way as any other game to add a sense of depth to surfaces in game we can now answer the open question of just where does Oblivion's parallax mapping come from.
The answer is that Oblivion's 'parallax maps' do not physically exist as separate 'maps' in the same way that other physical media does for the game engine (wall_d[iffuse].dds, wall_n[ormal].dds, etc.), its actually a specific utilisation of a texture channel that's present on another image, namely the alpha channel on the diffuse image (the "A" of the "RGBA" mentioned above); effectively the available 256 tones of black/white available in the 8 bit alpha channel are interpreted by the engine in such a way as to 'boost', or 'parallax', the sense of depth already present in the normal map. In layman's terms, that's all parallax mapping is doing in Oblivion, just boosting the sense of depth already present.
Design note : as mentioned in the above, Oblivion's parallax mapping is not a technically correct implementation of 'true' parallax, it's an approximation of parallax's main feature - additional visual depth.
So Oblivion's parallax system consists of two components;
Normal maps - actual physical media
Parallax 'maps' - alpha channel present other media (diffuse image)
To sum up some of the things learnt about Oblivion's parallax mapping;
Uses standard normal maps
Uses the alpha channel of the diffuse image
Images are 24 bit colour depth with an additional 8 bit mask channel (RGB+A - 8x8x8+8)
Alpha channels (masks) don't directly effect the colour depth of an image
Make use of the Blue channel - 'Z' axis (standard normal mapping ignores the Blue channel)
The Blue channel is used for 'depth / height' information
The data in each channel is relative to the others so can't be changed without effecting the other channels.
This seems like a lot of information to explain something relatively simple, however, it's fundamental information necessary to understand that parallax mapping in Oblivion makes use of standard normal maps; they the same in fact, it's just the implementation in game that's different. Once you understand this you can move on to creating your own textures without getting confused over the terminology that's often floating around the Internet in relation to creating custom artwork, not just for Oblivion.
Blender 2.5 hotkey chart
High-res printable chart mapping basic Blender 2.5 hotkeys
Entity chains & killing AI
RtCW SP & killing AI characters using simple triggered entity chains
GTKRadiant 1.4 set-up
Setting Radaint editor for use with custom content and games
Artists block
Solutions to the perennial problem of being creative
Blender Basics ambient occlusion
Baking and using ambient occlusion maps on models
Blender 2.5 'properties'
View and Transform properties in Blender 2.5
Optimising models
Learn to optimise low-poly meshes for games
Content is copyright © Quake3Bits & KatsBits 2000-2010. All Rights Reserved.
No part of this web site may be reproduced (except for personal use) without prior written permission from KatsBits.com. For more infomation on copyright click here.
Web design cpdt • Webmaster • Copyright © 2010 • Advertise • Privacy Policy
Resources
Downloads
