---

Textures

---

What is a texture?
It is an image that dresses, wraps around, a 3D model. Simple as that. In Fable, the textures are not JPG or BMP or PNG as you might be familiar with, but instead DDS. For those of you who are familiar with it, the textures are DDS:DXT1/DXT3. For those who don't know what that means, DXTn is a set of algorithms used in the compression of textures, something I will not get into because none of that matters right now.

Texture entries
Fable uses an archive to store textures, and each texture has its own entry. Actually, there are two archives (textures.big and frontend.big), but you're only going to use one and they're both essentially the same anyway, so we'll only be focusing on textures.big. I feel the best way to explain texture entries is to start out by showing you a texture entry.
Click here to see a standard texture entry.
What we've got here is a simple, blank texture. The texture itself doesn't matter in this section though, what does matter is everything else shown in the image. Let's make a list.

• Symbol Name
The symbol name is simply the name of the entry. It's best to have this be something memorable, relevant to its use and what it is, and in conformance with good practices (no spaces, all caps). Though you don't have to do any of that, it's how we've been doing it for years and it works perfectly. What you must do though, not optional, an absolute must, the symbol name must be unique. It can't share its name with any other entry. This is true for everything.
• ID
The ID is the unique identification number of that particular texture entry in the archive. This has no modding value and is best left alone. When adding texture entries manually, it's important to make sure that you don't skip a number. For example, if there are 6295 textures, the 6295th one should have 6295 as its ID. It's also a good practice to make sure that new texture entries have their IDs in numeric order, again not essential but that's how we do it because it's just better that way.
• Type
There are different types of textures, and these different types will have different type numbers. Their significance will be explained in detail in the next section.
• Dev Sources
This is where the developers put the filepath directories of the original textures on their machines. As modders, we can use this space to attribute credit to the person who made the modded textures, we can put in personal notes, we can write in there whatever we want, including but not limited to "Peter likes donkey balls." But I suggest using it for attribution.
• Entry Type
This is just a mundane display, but it's important because it tells us what format is being used for the texture. The importance of the format will be explained in detail in the next section.
• Width, Height and Depth
These are the dimensions of the texture itself. What's important here is that width and height will always be a power of two between 16 and 1024, and depth will always be 0.
• Frame Width/Frame Height
These are the dimensions of the frame of the texture, and the values will be equal to or less than the dimensions of the texture itself. These values determine what part of the texture is used in Fable. For example, if you have a 1024x512 texture, but you only want 640x480 to be shown (such as for a UI screen), you'll use 640 and 480 as the values for Frame Width and Frame Height. For the most part though, these values will always be the same as their counterparts.
• Frame Count
In animated textures, there will be more than one frame. Each frame will have it's own texture, but restricted to the same type, format, dimensions and frame size as the texture in the first frame. This is largely unimportant though as animated textures are only used in certain effects, and those effects mostly use a different and unsupported type of animated textures. For the most part, there will always be only one frame.
• Frame
Indicator for which frame is being shown in the display. Buttons allow the user to see the previous/next frame.
• Alpha
This is a boolean, which means it will always be either a 0 or a 1. If the texture has Alpha, it needs to be imported as DXT3 and this value should be kept at 1. If there is not Alpha in the texture, it needs to be imported as DXT1 and this value should be switched to 0 after import. Note: this value always switches to 1 by default on import - this is something to watch out for, because I'm tired of seemingly gigantic problems being brought up when the problem was a simply an alpha flag in the wrong position.
• Buttons!
There are various buttons all over the place and I can't have you guys tripping over yourselves because you don't know what they do, so...
Sub Header and Entry Data buttons, View Sub Header/Data, Export and Import are for dealing with the data in binary form. Typical users should never touch those buttons as they hold no modding potential unless you're into reverse engineering and are highly familiar with image formats.
Apply Changes, perhaps the most important button there. When you're all done editing the entry, you must click that button before closing the entry window, otherwise all of your work will be lost. This does not save the data to the archive though, so don't just close FE/CBox and start up Fable wondering why nothing happened. It just holds your edits into memory so that when you click Actions|Save Mods and Run Fable, it recompiles the archives with your edits.
Open New allows you to bring in a new image to replace the texture.
Add Frame adds a new image, but instead of replacing the existing texture, it just throws the new image in the new frame.
Save As... allows you to export the texture in a variety of formats so that you can edit them in an image editor of your choice.
• Preview
This allows the user to see the texture itself.

And this concludes our tour of the texture entry. Next stop, higher learning.

Different types of textures and texture entries.
As I said earlier, there are different types of textures. There are different types of texture entries. They're used differently, they do different things. First, let's cover texture entry types.

• Type 0 - Includes standard, alpha, specular and opacity textures.
• Type 1 - Animated textures.
• Type 2 - Bump textures.
• Type 3 - At the time of writing, I cannot find a type 3, and so cannot say what they are.
• Type 4 - Weather-specific graphic textures, unsupported.
• Type 5 - General effect textures, unsupported.

Yes, I mentioned eight types of textures in five texture entry types.

• Standard. Click here to see a standard texture. Same as the one above. That's because it's standard. These are the most basic, their only job is to wrap around a model, nothing special.
• Alpha. Click here to see an alpha texture. The alpha is what's shown in purple. The texture itself has no purple (it's actually completely black), that's just the representation of what is alpha. Alpha is transparent, means see-though, means that where it goes over the model isn't going to be seen. It doesn't have to be completely transparent, you can have alpha in varying levels from 0 to 255, or 0% to 100%, depending on what image editor you're using.
• Specular. Click here to see a specular texture. A specular texture goes over the standard 'base' texture and adds shine to a model. It simulates the reflection of light, parts that are black reflect no light and lighter parts reflect more light. These are generally grayscale.
• Opacity. Click here to see a opacity texture. These are also generally grayscale. An opacity texture goes over a base texture that doesn't have alpha and it gives it alpha. The understood reason for using this instead of alpha is so that you can use the same base texture and different opacity textures which is easier and makes more sense than having a bunch of the same texture with different pieces of it alpha'd out. There's irony in this because I only see one instance of the opacity mask, the ghost sword, and there's only one ghost sword texture and one ghost sword opacity mask, yet there's tons of duplicate textures that are exactly the same. So a smart idea done wrong by the developers, you can use this to do it right.
• Animated textures. Click here to see two frames of an animated texture. These are mostly for effects yet are largely unused by effects, which perhaps in the transition from original to TLC probably got an upgrade because they now use the unsupported effect textures. Anyway, there is no practical way of implementing animated textures into the game, unfortunately, and so don't hope to use them.
• Bump textures. Click here to see a bump texture. These are really cool. It would be impractical to make a highly detailed model with a lot of grooves and scratches and such, because that would mean a lot of vertices which would slow the game down. Instead, you can use a bump maps which goes over the base texture, and the darker colors make the model appear recessed and the lighter colors make the model appear raised. A good example of that is the blue will markings that the Hero gets. These are actually inverted bump masks, which I think must have been an accident because it's actually very smark as it allows the DDS format to retain higher quality textures. In the strictest sense, these are not really bump maps but instead standard maps that are used as bump maps. But this is actually a good thing, because nVidia released a normal map filter that allows the easy creation of Fable "bump" maps, they just need to be inverted for use in Fable.
• Weather textures. Click here to see a weather texture. Unsupported (as you can tell from the image), don't touch these. Many of them have strange entry formats, but most of them are standard DDS. Until we can find a way to read and edit the entry data, there's no chance of editing the texture data. One entry in particular has the format of ARGB8888, or 32bit BMP. Crazy stuff.
• Effect textures. Click here to see an effect texture Like weather textures, these are unsupported. Still most of them are DDS, but that entry data is just crazy, I can't make heads or tails of any of it.

Congrats. That's the extent of my knowledge on Fable textures. At least, that's the extent that I'm willing to share with the general public, which should suffice. Next on the docket is models. Good luck - you'll need it.

---

Addendum

---

Bump, specular and alpha masks.
As I said before, these things are really cool. But I didn't show renders that displayed how cool these things were. So I've put these together for you.By combining these really cool things with a really good texture and model, and cool model effects that you'll learn about later, what you've got is pure awesome. That's why I am teaching this, we need more awesome in our mods.

---

Models

---

What is a model?
A model is basically a database of information that forms a 3D form. They contain wealths of information: mesh, element count, vertex count per element, vertex coordinates, which connecting vertices form triangular faces (everything breaks down into triangles), vertex normals, texture coordinates, material/texture listing, skin weights, etc. In Fable, the models are stored in individual entries in the graphics.big. The format for the models is not entirely cracked... we still don't have support for raw entry data, instead we use the tools to convert the parts of the models that we do know into DirectX (which comes closest to what's there), and we convert the DirectX back into the raw data on import. This affects a lot of things, but right now none of that matters unless you're a hardcore reverse engineer familiar in model formats with some experience in writing 3DS plugins, and since you're not one of those guys, you'll just have to be content with what info I give you.

Graphics Entries - Welcome to Hell.
There is a lot of crap stuffed in this, so bear with me.
Click here to see a standard graphics entry preview.
Click here to see a standard graphics entry submesh data.
Click here to see a standard graphics entry material data.
I don't even know where to start... Let's just outline what we see here and work our way from there.

• Symbol Name
The symbol name is simply the name of the entry. It's best to have this be something memorable, relevant to its use and what it is, and in conformance with good practices (no spaces, all caps). Though you don't have to do any of that, it's how we've been doing it for years and it works perfectly. What you must do though, not optional, an absolute must, the symbol name must be unique. It can't share its name with any other entry. This is true for everything.
• ID
The ID is the unique identification number of that particular graphics entry in the archive. This has no modding value and is best left alone. When adding graphics entries manually, it's important to make sure that you don't skip a number. For example, if there are 8113 textures, the 8113th one should have 8113 as its ID. It's also a good practice to make sure that new graphics entries have their IDs in numeric order, again not essential but that's how we do it because it's just better that way.
• Type
There are different types of graphics entries, and these different types will have different type numbers. Their significance will be explained in detail in the next section.
• Dev Sources
This is where the developers put the filepath directories of the original textures on their machines. As modders, we can use this space to attribute credit to the person who made the models, we can put in personal notes, we can write in there whatever we want, including but not limited to "Peter likes donkey balls." But I suggest using it for attribution.
• Entry Type
This is just a mundane display, in the graphics entries, all it will say is model... or nothing, depending on the type of entry.
• Select LOD
A graphics-specific (as in not in textures) function. Some graphics entries are broken down into less-detailed models, for use when they are far away and can't be seen well enough for anyone to tell the difference. The trade off is quality for speed. The buttons allow for users to switch between LODs, 0 being the highest quality and the last one being blank. It is suggested that for modding purposes, you load a mesh over an entry with the fewest possible LODs, and load the same mesh over each LOD except for the last one.
• Buttons
Sub Header and Entry Data buttons, View Sub Header/Data, Export and Import are for dealing with the data in binary form. Just like the textures, typical users shouldn't ever play with these buttons as they hold no modding potential unless you are extremly talented in reverse engineering and know a thing or two about model formats.
Apply Changes (copied from the textures section), perhaps the most important button there. When you're all done editing the entry, you must click that button before closing the entry window, otherwise all of your work will be lost. This does not save the data to the archive though, so don't just close FE/CBox and start up Fable wondering why nothing happened. It just holds your edits into memory so that when you click Actions|Save Mods and Run Fable, it recompiles the archives with your edits.
Save Model LOD, converts the raw entry data of the current LOD into DirectX and saves it in a friendly plain-text format for you.
Load, takes a DirectX model and loads it over the current LOD.

And now section-specific stuff.

Preview tab
• Just a display of the mesh, rotating. If it's an animated mesh, you can drag and drop an animation entry from the tree-view over the display and the mesh will use the animation. This is shown later.
SubMeshes
• Is used to assign Material ID numbers to specific submeshes. No modding potential and it is best to just leave this alone.
Materials
This is the real meat of this entry, with all kinds of fun stuff in it.
• Materials - a list of submeshes in the graphics entry. Selecting one brings up the rest on the right side of the panel.
• Material Name - Friendly name of the submesh. It is important (absolutely imperative) to follow good practices with this, explained below.
• Material ID - Is used to assign an ID number to specific submeshes, operates independently of the Material ID used in the SubMeshes tab, but still has no modding potential and is best left alone.
• Base Texture ID - The textures.big ID number of the base texture.
• Bump Map ID - The textures.big ID number of the bump map if one is used, 0 if unused.
• Specular Map ID - The textures.big ID number of the specular map if one is used, 0 if unused.
• Max Texture Layers - A bitwise code to determine what types of maps are used on the submesh ranging from 0 to 15. Codes explained below.
• Material Alpha Enabled - Boolean (means either 0 or 1). If the base texture for the submesh is DXT3:Alpha 1, this value will be 1. If the base texture is DXT1:Alpha 0, then this value will be 0.
• Glow Strength - Adds a glow to the submesh. Ranges from 0 to 255 (0% to 100%), which is plenty.
• Unknown1 - The textures.big ID number of the alpha/opacity mask if one is used, 0 if unused.
• Cloth Enable - Boolean; indicator of dynamic mesh. Since no new or edited mesh will have dynamic mesh, this value will always be 0.
• Unknown3 - Boolean; indicator of dynamic mesh interactions. Since no new or edited mesh will have dynamic mesh, this value will always be 0.
• Unknown4 - Boolean; indicator of Degenerate Triangles. Since no new or edited mesh will have Degenerate Triangles, this value will always be 0.
• Apply Changes - Very important. If you edit the submesh properties table, click this Apply Changes button first, then click the upper Apply Changes button, else it won't work.

Material Name
If you're going to edit meshes, you must follow these good practices, or else you are likely to experience problems and I'll laugh at you and say "I told you so."

• Material name must not start with a number.
• Material name must not have any mathematical function in it, like +-*/&^ or etc, stick to A-Z, a-z, 0-9 and underscores (_).
• If you're going to export a mesh, first rename the submeshes to comply, and be sure to apply changes properly. No need to recompile the archive as the edit is already in place, after applying changes, just export.
• Avoid certain words, like 'sword', 'dword', 'byte', 'ubyte', 'sbyte', 'long', 'ulong', 'slong', etc. These are used in data interpretation and will make the mesh seem to be broken if you try to use it. Specifically 'sword', don't use it.

Max Texture Layers
This is a fun one. It is bitwise. It is easy. So, there are four types of maps, base, bump, spec, and alpha. Each of these has a designated number:

• 1 - Base
• 2 - Bump
• 4 - Spec
• 8 - Alpha

So you just add these up based on which maps are being used, and use the sum as the value for Max Texture Layers.

• 0 - No maps.
• 1 - Base map only.
• 2 - Bump map only.
• 3 - Base map + bump map.
• 4 - Specular map only.
• 5 - Base map + specular map.
• 6 - Bump map + specular map.
• 7 - Base map + bump map + specular map.
• 8 - Alpha map only.
• 9 - Base map + alpha map.
• 10 - Bump map + alpha map.
• 11 - Base map + bump map + alpha map.
• 12 - Specular map + alpha map.
• 13 - Base map + specular map + alpha map.
• 14 - Bump map + specular map + alpha map.
• 15 - Base map + bump map + specular map + alpha map.

Since every submesh will have a base map, that leaves 1, 3, 5, 7, 9, 11, 13, 15. There you go, have fun.

Notes
Click here to see a screenshot taken by Marcopolo. Notice the ghost swords. Remember that they're supposed to be using opacity/alpha masks. Notice that they're not the least bit see through. It is possible that opacity/alpha masks don't work, which might explain why LionHead only used one instance of these. Though, Marcopolo didn't have his graphic settings all the way up, so it might be possible that they do work. I refuse to test this, so to be safe, do it the LionHead way, just put alpha directly on the base texture, DDS:DXT3:Alpha 1, Material Alpha Enabled:1. When loading a mesh, it will show up blank white. The Material settings for each submesh will be set to 0, so you'll need to edit them. Remember to apply changes properly. Only the base texture is shown in the preview panel. Glow, special maps, etc. and so on will not be shown and will have to be tested in-game. Moving on to the next section...

Different types of models and model entries.
There are different types of models and so there are different types of model entries. Like with textures, different types of models are used differently, do different things. Thankfully, these are not so complicated as textures. Let's get started with entry types.

• Type 1 - Static; Click here to see a type 1 graphics entry. These are things that don't move. The key difference between these and animated meshes is that these have no bones and so can't use any animations. They can still be moved when mounted to an animated mesh, like the Hero (animated mesh) swinging a sword (static mesh). Weapons (except long bows and pump action crossbows), structures, buildings, all static meshes.
• Type 2 - Landscape; Click here to see a type 2 graphics entry. These include grass, falling leaves, flowers, things of that sort. They do not include the actual Fable landscape itself (that's in the STB, different discussion). They're largely unsupported and generally don't work for editing purposes, as they follow a different format.
• Type 3 - Collision; Click here to see a type 3 graphics entry. These can be attached to certain static (type 1) and animated (type 5) entries. Anything the Hero isn't supposed to walk through, like walls and buildings (both static) or closed doors and chests (both animated) will have a collision mesh. FE doesn't support these, but ChocolateBox does. Click here to see a type 1 graphics entry with collision in CBox. Notice the part that says "Physics". The number indicates which type 3 entry is used as collision. Click here to see a type 3 graphics entry in CBox. The Hero will be unable to cross any face of the collision mesh.
• Type 4 - Effect; Click here to see a type 4 graphics entry. These are much like the landscape meshes, similar format, and so are also unsupported. These are for use in certain effects, like the exploding zombie will throw out little zombie bits. Cool stuff. But we can't use them so... moving on.
• Type 5 - Animated; Click here to see a type 5 graphics entry. Creatures, clothing, hair, the windmill sails, opening doors and chests, long bows and pump action crossbows, all animated meshes. They will all have "bones", nodes that influence the movement of vertices in the mesh that are weighted to them, which the animations move around to create the animation.
• Type 6 - Animation; Click here to see a type 6 graphics entry. By itself is nothing. The animations, as mentioned earlier, move around the bones in animated meshes to create animation. They also trigger sounds and effects at certain points and certain times, which make it a painfully difficult format to understand. They use quaternions as opposed to matrices to create animation, but that's boring stuff. More important is that these cannot be easily edited to any useful extents, but it is possible to edit them. You can preview the animation by dragging and dropping the entry over the preview window of a compatible animated (type 5) entry, which gives you this. All in all, animations represent a lot of potential that cannot be fully realized until we have better tools, something that is not likely to happen.
• Special - Dynamic mesh; dynamic mesh isn't bound to any one type, but is generally found in certain static and animated meshes. Examples include flags, hair... anything that can move with the wind. Imagine twirling around a rope, it is dynamic. That's what dynamic is. But since dynamic mesh used in Fable uses a different format, it is unsupported, converted to static/animated mesh on export, and is stripped on import. So you won't be using this.
• Special - Degenerate Triangles; these lovely and magical triangles minimize filesize by welding together all vertices that meet at one point but without causing any decrease in quality. Wonderful little things. But it's converted on export and stripped on import because it's not supported so you won't be using these either.

Important Notes - Like so important that you absolutely need to read this right now.
The graphics formats aren't completely known, the known parts are just converted to DirectX and back on export and import. It is for this reason that you must load meshes over a similar mesh entry. On export, many things are lost or jumbled, but not always. It depends on which mesh you're using. Sometimes texture coordinates get all mixed up. Sometimes vertex coordinates are off. Sometimes meshes don't work at all. Sometimes submeshes get merged together even though they use a different texture. But usually things work out just fine, or if not, are easy to fix in an editor. Note that the only editor that can be used properly for animated meshes is 3DS. Also note that the only editor that can utilize helpers and proper hierarchy structures is 3DS. And further note that the only DirectX plugins available for 3DS are mofo's Xporter import/export plugin and Andy Tather's Pandasoft Exporter plugin. And lastly, note that mofo's Xporter plugin can potentially botch the import of animated meshes, screwing up the weighting, thus creating a nightmare for anyone wanting to edit animated meshes.