Texture and File Sizes in URU

[Calena]

SIZE OF TEXTURE IMAGES

Anyone who has been building for more than a day or two is probably already aware of the constant reminder to keep the texture sizes small and not add unnecessary bloat to the texture.prp file. Okay. Message understood. But what does it really mean to us when we're building an age?

Emor sent me on another fact finding mission . Here's a fact:

* I added all the actual image sizes together of my test age and total original image size came to 11,558Kb. That number assumes that the images used on multiple objects in the test age are only imported once into the .prp file. Then I deleted the texture.prp file from the .dat folder and exported a fresh file. The plugin compresses the texture files on export. Total .prp file size after export = 1,796Kb. That's an almost 85% compression rate! What I'm not clear on is if it's the size of the .prp file that matters, or if the images are de-compressed during runtime, in which case the size of the .prp file becomes irrelevant. *

Another fact I discovered during this exercise - I took a look at the texture.prp file via PlasmaShop and discovered that the file was keeping every . single . image I had ever exported with the age, including those that were no longer in use. It appears to just keep adding new images without ever deleting the old ones. So, if you notice your texture.prp file getting extremely bloated, you just might want to try deleting it and doing a fresh export (wish I could loose weight like that ).

Another fact is that at this time, we don't actually have a maximum safe texture.prp size for reference. Most of the documentation references the standards set when Cyan originally built the game, but those standards are completely out of date now. It is my understanding (someone correct me if I'm wrong) that the size of the video card's RAM can be used to decide a safe target size for the texture file. Recommended GPU RAM on Cyan's website is . . . would you believe 32Mb ! I have very inexpensive video cards, but they all have 1Gb of RAM. I think maybe we can be more generous with the size of that texture.prp file.

One thing I have no way of knowing at this time is how or even if this effects online servers with multiple players in different ages. I think it's still dependent on the client side hardware.

[SRFSR2B]

The following discussion is based on looking at how Blender/PyPRP handles texture conversion for URU; I have not yet had the time to confirm that Plasma converts in exactly the same way. But I will double-check this and confirm in upcoming months!
___________________________________________________________

Plasma uses textures in the .dds file format. Now, I understand this has efficiencies in its compression methods and how well it integrates with Direct X. But some other things about it have always perplexed me.

Here's why:
in normal RGB displays a pixel's Red, Green, and Blue colors are represented by eight bits of information for each color. Red, Green, and Blue together adds up to 24 bits of data. The addition of an alpha channel for transparency (RGBA) adds another eight bits, for a total of 32 bits per pixel (see RGBA color space).

It doesn't matter whether you've saved your original texture image file as a non-alphaed .tif,, .jpg, or .png image. It doesn't matter how nicely you've compressed the original image, or how effiiciently you may have optimized the image palette (a la Photoshop's "Save For Web & Devices..."). It doesn't matter if you only have one pixel of black in the middle of a solid 1024X1024 white (or transparent) background. The DDS conversion saves in the same file sizes, no matter what. This is very inefficient!

As with the standard RGB pixel data above, the addition of an alpha channel (for transparency) should simply add another 1/3 - another eight bits - to the size of a 24-bit color image.
But the Plasma .dds alpha conversion instead DOUBLES the size of each resulting texture file!

   

Note the 8X difference between the size of a 512X non-alphaed and a 1024X alphaed image!

The other thing to note is that Plasma only uses images in multiple-of-two sizes: 16X16, 32X32, 64X64, 128X128, etc.
If your image is NOT formatted in a multiple-of-two size, the conversion process will scale your image UP to the next suitable multiple-of-two texture size.

In other words, if your original texture is 256X256 pixels, it will convert to that same size. But if it is a 257X257 image, conversion will scale it up to a 512X512 .dds file. You will have effectively lost 3/4 of the image resolution you could have had if your file was originally made as a 512X512 image!
So: build your original images in multiple-of-two sizes in the first place!

That said, Plasma does handle 1X2, 1X3, 2X1 and 3X1 variations of the above sizes just fine. (so something like a 128X384-ratioed texture should process correctly)

[Calena]

I've been doing my homework on this and I've gained a good bit of useful insight. I'm going to try to organize this information so that it can be useful to other builders.

1.) The first thing to decide is the maximum target file size we want for our texture.prp file. This is a dynamic number which can and will change as time goes on. It's important to understand that all graphic images are processed by the GPU, not the CPU. The CPU processes the logic and animations, not the graphics themselves. Since the processing units work independently of each other, the size of the graphics file does not contribute to lag unless it gets larger than the GPU. I'm going with a very conservative number because I want to build for inexpensive computers that are 5 - 6 years old, so I'm going to limit my texture file size to no more than 256Mb. The actual size of the texture.prp file equals the amount of memory used by the GPU. Note: some of the older game engines had a 100Mb limit coded into the core system. I don't know for certain whether or not this applies to Plasma, but I tested exporting a 125Mb texture.prp file and had zero problems. Everything rendered perfectly.

2.) The Plasma game engine uses the industry standard .dds graphic file format, which was designed to utilize DirectX graphics. (NOTE: This is beginning to change as DirectX gets updated, but Plasma is still using the older DirectX). The plugin uses the generic conversion method known as DXT to "compress" the image files and convert them to .dds format. We can choose whether or not we want the plugin to compress the image by putting a check in the box to turn off file compression.



I've tested it and the game engine already has the capability to render uncompressed high definition images. It works!!! Of course, if we're working on a large complex age with hundreds of images, we're going to need compression.

3.) The manner of compression is called color interpolation. This is what causes high definition images to loose their definition. Here is an explanation of this compression method that I found useful:

DXT Compression Explained

The age I'm working on currently has 431 texture files, but only 3 high-def images in it right now. The texture.prp file is only about 80Mb. So much for using the same image over and over and over to save space .

[Hub Goobley]

I'm going to limit my texture file size to no more than 256Mb.

256 Megabytes??!!!???
....that's more than will fit on my whole hard drive!

   

[Emor D'ni Lap]

Holy Moby Dick, Cap'n AHub -that looks like a whale of a huge drive - for only 250MB! It's HUGE!

Calena, thank you for the info on compression...do you have any estimates on the loss of texture quality with compression, or the gain when we don't?

If I had a bit more time, I'd set up some side-by-side panels, texture them with identical resolution charts, put a "normal" setting on one and "do not compress" on the other. I wonder what they'd look like after Plasma export.

I'd test what this looks like using a 1024X file, a 512X file, and a 256X file applied to the same size panels. I bet compression would start to become apparent at some point...but knowing where could help builders know when to economize and when to splurge on file space.

[Calena]

Holy Moby Dick, Cap'n AHub -that looks like a whale of a huge drive - for only 250MB! It's scary big!

Hub, if you owned that HD at the printed manufacture date of 1993, you would have been one of the elite of the elites! 256Mb in '93 was almost incomprehensible to the general population. If memory serves me correctly, I had just taken possession of my new "big" computer that had 4Mb of RAM and a 40Mb HD. We're in a different world today.

Calena, thank you for the info on compression...do you have any estimates on the loss of texture quality with compression, or the gain when we don't?

Sorry, all I have right now is the anecdotal evidence of my own eyes. I can see the difference. One thing I've learned though is that the effect of compression can differ from image to image. The more colors and subtlety in the original image, the more likely compression will have an increasingly negative effect on what Plasma ultimately renders.

If I had a bit more time, I'd set up some side-by-side panels, texture them with identical resolution charts, put a "normal" setting on one and "do not compress" on the other. I wonder what they'd look like after Plasma export.

I'd test what this looks like using a 1024X file, a 512X file, and a 256X file applied to the same size panels. I bet compression would start to become apparent at some point...but knowing where could help builders know when to economize and when to splurge on file space.

I agree that more concrete facts would be helpful when decision making time comes in age-building.

I'd like to see a chart that clearly illustrates what does/does not contribute to lag and the percentage of each - something along the lines of animations contribute 50%, collision contributes 20%, real time lighting adds 10% (numbers completely made up here) and so forth. For online installations, bandwidth is also a big contributing factor.

All I've ever been able to find is admonitions to be careful! Okay, but could you be more specific ? Be careful where, how, why, what and when? And could you please put that information in a simple to understand chart and post it somewhere obvious?

If I ever get a good understanding of all of this, I'm going to take the time to make and post that chart .