One thing to keep in mind is the larger the canvas, the more detail you can include in the painting.
The UV or image is what we call the wrapper or skin. Each area of the image has been assigned to the UV by the original object software... in my case... I use MAYA 4.5 or MAYA 9. You cannot change the location of the hull, for example and expect it to work. It is already defined to reside in a specific x, y position on the canvas.
When you start with a larger image, you have more pixels within the region of a part of the skin, thus you can have a mixture of color or lines or whatever is required.
As I stated earlier, the size of the canvas does not matter, the location assignments stay the same. We call this aspect ratio. You will see that term a lot in most graphics software... GIMP is no different. Example: if the x (width) changes, y (height) must also change. Since we want the image to stay the same, aspect ratio ensures that x and y are adjusted at the same ratio. From time to time, you will see decimal number as to the size, these must be set to the number of pixels, not in inches, millimeters or any other measurement. You will find the measurement scale options in various places in the software for different function. But pixels is the default measurement so no change is necessary.
Another very important thing to consider. The canvas should be a factor of 32 as to the x, y measurements. Meaning the size of the image should be measured in pixels (width and height) and should be no less than 32 x 32 or an aspect ratio of 32... 64 x 64, 128 x 128, 256 x 256, 512 x 512, 1024, 1024, ext... We essentially increase the size by doubling the canvas aspect ratio (x, y) each step up in size. The majority of Blitzkrieg Models use 128 x 128.
So let's consider what happens to pixel assignment as we increase the canvas size...
Example: We started with an image of 128 x 128, but we wish to change it to 256 x 256.
Well obviously we have to cover more surface, so the existing pixels have to change. Most people might assume you would be doubling the number of pixels, but that is wrong. One pixel color must not be adjusted to two pixels, but 4 pixels. The aspect ratio must be changed in both x and y. So now one pixel must occupy two pixels each direction... so 2 x 2 = 4.
If we had changed our image size from 128 x128 to 512 x 512. This not increasing the size two steps, but 4 times. The same pixel would have to cover 4 pixels each direction... 4 x 4 = 16. So we can understand why the image will now look fuzzy or blotchy. We are using more pixels for the image, and most of the colors are in 16 x 16 groups or squares. If the same color was used next to each other in other pixels, you may have huge blobs or squares of the same color all around the image. Aspect ratio has made sure the size of each pixel assignment has changed.
One final thing to consider is the file size of the image. When Blitzkrieg was first released in 2001, part of the conventional thinking at the time was how to do a lot with very little. Computers at that time did not have the same amount of memory a or storage space, I'm referring to RAM and Hard Drives. Very few people could afford to buy memory sticks at $200 to $300 a stick for a couple of mb, and huge hard drives were hard to find. On another note, graphics on most computers at the time were onboard, meaning they were incorporated into the motherboard. The most common was the S chip. So graphics were not as good as todays.
Time changes everything. Today's computer have exponentially improved over the computers of the late 1990s to 2005. What did not change was the original Graphics on Blitzkrieg. So the players started to push the limits of the game. We discovered that the open architecture really allowed us to overhaul everything. So far, we cannot change the hard-coded things that still prevent a true overhaul. I hope this will eventually happen.
Ok, so back to the thinking of the day. NIVAL realizing computer RAM, Hard Drive Space and Graphic Capability was going to be an issue for most players, made some very intelligent decisions in the game development.
1) The terrain items would be 2-D objects
2) Soldiers would be 2-D sprites using image-flipping for animation, a very old technology, but quite effective.
3) 3-D objects would have very few polys, or triangles making their files size very small. This also was for the purpose of rendering and animating the object within the limits of the graphic capability.
4) Developing a structured object folder system where each type of file had a defined location, and thus purpose by design.
5) All objects and codes would be stored in .pak files using the same folder structure. So why a .pak file? As standard practice, developers don't give away the farm... so if they simply used .zip, how long before we figured that out? But in the case of NIVAL, they placed no limitation on how the files were to be used, so they actually pointed to the .pak files and said... "hey guys, those are just .zip files". The objects were 'packed' to save hard drive space. it didn't take us long to un-pack the .pak to see what was in there... (NOTE: I unpack everything... there is no point or advantage using .pak files today, except in a few cases).
These five things changed computer games forever. Because NIVAL lead the way by opening the door like no other door had been open for a game. They gave us the tools and capability to truly change BK, and push the envelope. So why pack files? Well they were cleaner and easier to compile for mods. Today the file size is not so much an issue for Blitzkrieg. I have tested skins or model textures up to 2028 x 2028... think about how large that is... but they work. But the file size is also huge. I typically use 512 x 512 because that comes in around 1 mb for the files size, or weight as I call it.
Original BK model had very few polys or triangles. Triangles? All 3-D models are created by using basic objects like rectangles, circles or spheres, then changed to form the model parts. Every part we use are called polygons... See where the tem poly comes from? A polygon is nothing more than an object that has vertices and faces.
Example: If I create a square, it has six sides. Each side is called a face. Each side is defined by the points x, y or z. Ok, you must think in 3D here, in other words, begin to think spatially in you mind. We can rotate this square so we can see every face, but we can never see all of them at once. So when we create a part for a model, we only need to use the faces that will be seen by the player in the game... we can discard the others... that reduces some of the weight on the overall model. Back to those points for a moment... the points define the size of each face... but we don't call them points, they are vertices. Vertices is plural for vertex. If we measure a width of a face, we are measuring from vertex a to vertex b. Same for the height or depth... we are measuring from point to point. These vertex (sp) are what give our model the shape. But the more vertices, the more polys, and then more triangles.
Ok, again... that word triangle... where does the triangle come into this?
Before we can use the model in the game, we must triangulate every face... meaning the model in its final form is made of faces defined by triangles, not the squares or circles. Wherever there is a face, it must be changed to a triangle. This does not change the part, it just sub-divides the face into triangles. So if we are looking at one surface (side) or face of our square... once triangulated, instead of a face being defined by 4 points or vertices... the face is divided into triangles... in this case we now have two faces... because a line is simply used to define the new face by using two vertex in opposite corners or whatever the position may be.
OK Major, you have bored us with all of the geometry and graphics stuff... what is the point? 
As I mentioned, NIVAL used low poly count 3-D models and small skin images for a purpose. To pack in a lot of stuff using very little resource. They did this so BK could run on computers that had little memory and hard drive space. And the on-board graphics limited the way the models or terrain could be manipulated... displayed.
Well most of the limitations are not a factor today.
Example:
Look at the file size of the BK model
M4A3E8_HSVV... 366 kb
Now look at the 1_h.dds fle size... 257 kb
Look at the 1.xml file... 7 kb
You will also find other files for that model...
The model itself is a low poly count, meaning it does not have a lot of polygons thus fewer triangles. The triangles are what define the model in the final weight or file size.
Now let's compare one of my Shermans
I'll use my version of the Easy Eight tank:
US_M4A3E8(76)W .... 1,219 kb ( 1.2mb)
The 1_h.dds .... 1,025 kb (1 mb)
the 1.xml... 7 kb
There is a significant difference between the two models in terms of weight or files sizes.
My model is basically 4 times the weight... or uses 4 times the resource or hard drive space.
The Skin is basically 4 times the weight or size...
Once you add each season skin with the death skins... you are using more hard drive space.
Anyone remember when your programs were on a Colorado Tape Drive, or Cassette Tape?
That was before we had todays Hard Drives, Thumb Drives, Scsi Drives, etc... Today I have hard drives that are 1 tb - terabyte. In 2000, that would cost you a ton of money, thousands, Today, less than $75 US. So space is no longer an issue for object storage.
So how does the object weight figure in the game?
Well the skin size or weight really doesn't. That is only an image or wrapper that defines the faces of the models. As long as your skins is 128 x 128, 256 x 256, 512 x512, etc... it really doesn't care. In some cases you might even see skins sizes of 64 x 128, or 128 x 256. Still doesn't care.
Well that high poly count model uses more memory... right?
Yes, but the game still renders the model just fine. It has the capability to adjust to the objects. Look at the Karl for a moment... 154 kb. You would think because of the size of the model, it would use more resource... Nope, it is about the number of polys and triangles, and not the overall size. In other words, Size does not matter, unless you create something that cannot be displayed on the screen... then the game is going to stroke out...
The point of this post is to educate not just dragon... but anyone who skins or creates models or objects. You're not handicapped by staying within a certain boundary.
Use the 512 x 512 skins... the more detail even on low poly count models improves their appearance.
Model builders, don't worry about the detail you want to include, but don't go overboard.
If you can't view the model in your tanks viewer, then it does not mean it won't work in BK...
I just tested a model that weighs right at 2 mb... this was only a test model to test the isotropic display limits of BK... it worked perfectly. Does this mean I going to build everything in the future around that size... no I build what I think I need and don't worry so much about the weight. It is common on my newer models with 3D tracks and suspensions they weigh around 1 to 1.2 mb. And they work fine.
NIVAL gave(well actually sold) you a game that had more punch and ability to be changed than any of us ever realized in 2002-03. My thinking is that we have not yet exploited the limits of the game engine and architecture. We have not found the ceiling. When we do, then we will work with it.
So get those creative juices flowing and build something...
I hope this was somewhat helpful...
if not... well that was five minutes you will never get back...
Sorry...
That was before we had todays Hard Drives, Thumb Drives, Scsi Drives, etc... Today I have hard drives that are 1 tb - terabyte. In 2000, that would cost you a ton of money, thousands, Today, less than $75 US. So space is no longer an issue for object storage.
Well the skin size or weight really doesn't. That is only an image or wrapper that defines the faces of the models. As long as your skins is 128 x 128, 256 x 256, 512 x512, etc... it really doesn't care. In some cases you might even see skins sizes of 64 x 128, or 128 x 256. Still doesn't care.
Yes, but the game still renders the model just fine. It has the capability to adjust to the objects. Look at the Karl for a moment... 154 kb. You would think because of the size of the model, it would use more resource... Nope, it is about the number of polys and triangles, and not the overall size. In other words, Size does not matter, unless you create something that cannot be displayed on the screen... then the game is going to stroke out...
Sorry...