Optimised image use
From LightWiki
back to the Tutorial Ideas page
<Ed: This tutorial needs images to illustrate mip-mapping and other elements>
LightWave seems at first glance to be a memory hog when it comes to image maps, but careful usage can result in a lot more available memory. Here's a guide to getting the best from your image maps.
By Ben Vost and Michael Wolf
Contents |
First, some definitions
A surface has channels which can be textured using texture layers that consist of gradients, procedurals and/or image maps. For channels here we mean Color, Diffuse, Reflectivity and so on. We will be concerned with image map-based texturing in this explanation.
We also need to define images now, since they have become a lot more complex than back when we could just say Jpeg or IFF. Palette-based pictures - those using a fixed palette of 256 or fewer colours, can be referred to as single channel 8bpc (bits per channel) images, but this is confusing, so we'll call them palette-based in this document with no further definition.
What used to just be called 24-bit images are better known now as 8bpc images, to separate them from the higher definition images such as openEXR (16bpc) or Cineon (10bpc) or LightWave's own FLX (32bpc) that can have more bits per channel. The number of bits per channel determines how accurately the colour will match reality - an 8-bit channel will be able to choose between 256 levels, but LightWave's 32-bit channels have over 4,000,000,000 levels to choose from.
General notes on image creation for texturing
First off, DPI or PPI has nothing to do with measuring your image size for LightWave texturing, the only thing of importance is pixels. DPI and more correctly PPI are modifiers to measure those pixels on real-world scales. That's to say that an image called "OurSquare" that is 1000x1000 pixels can be 1 inch square if using a PPI measurement of 1000PPI, or a 10 inch square if using a measurement of 100PPI - all that LightWave is concerned with is that initial 1000 pixel square image (the screen or web default of 72PPI or DPI is fine).
| Here is a 300dpi JPEG image: |  |
Secondly, what size should you make your image? Well, the rough rule of thumb is 1.5x the size the texture will appear onscreen. This means that if you are working at a standard PAL video resolution of 768x576, your images will never need to be bigger than 1.5x768 (1,152) by 1.5x576 (864) in pixel size for an image that completely fills the screen. Of course, most things won't get that big on-screen, and if they do, better to go to 2x, or even 2.5x the base resolution to be on the safe side. What you won't need to do is generate a 4k image map for a TV shot. If you are creating a plaque to go next to the front door of a house you will be seeing whole at PAL resolution, you know that the thing will only be tiny in any shot (unless you zoom right up to it). This means that you can get away with an image at a lot lower resolution - its lack of fine detail will never be seen.
Thirdly, image use in LightWave is either based on uncompressed 8 bits per channel or 32 bits per channel images - palette-mapped pictures containing 256 or fewer colours are still 8 bits per channel, but only have one channel instead of 8-bit Red, 8-bit Green and 8-bit Blue. If you need to have 257 or more colours in your picture you may as well save it in a true colour format like TIFF, JPEG or best of all PNG, since LightWave will treat it as full colour internally anyhow. It will also work with the images in the same way that most applications deal with images - that's to say, if we're using OurSquare in 8 bit per channel colour and the JPEG file is only 300k on the disk, that's great for your disk but doesn't make any difference when it's loaded. Most applications only deal with the uncompressed image data once the image is loaded into RAM, thus the uncompressed size of this image is 1000x1000x3 in bytes or roughly 2.9MB, which is how much memory it will use in LightWave.1
Colour images
The only images used to surface that need to be colour are the ones used in the colour channel (or colour channel texture layers to be more correct). LightWave will treat palette-mapped images as 8-bit images in memory, so if you are using an image to create that two-colour industrial yellow/black stripe pattern, there is no need to save it as a 24-bit file. Save it instead as a palette-mapped PNG and save lots of disk space as well as memory.
Using PNG
Your JPEG files may be nice and tiny on your hard drive, but they still take up an uncompressed amount of room in LightWave (and any other application making use of them), and are never equal to the original image they are taken from. A tip for those wishing to avoid such problems is to use PNG for your image maps. The file sizes on disk are somewhat larger than JPEG, but the quality is never compromised from your original picture (PNG uses lossless compression). In addition, while JPEG files only support 24-bit colour and 8-bit greyscale images, PNG also supports Alpha channels as well as palette-based colour images. All in all, it makes for a perfect file format for image use inside LightWave. Our example OurSquare image saved as a JPEG comes in at roughly 2.9MB when rendered in LightWave (plus mip-map costs). The same image saved as a palette-based PNG would weigh in at roughly 976k (plus mip-map costs) when rendering.
Using HDRI
HDR images are a different kettle of fish in use. LightWave stores HDR images as 32bpc floating point. As a matter of fact, any image with more than 8bpc is stored as 32bpc floating point in memory by LightWave (this includes for example: 10bpc cineon, 16bpc TIFF or 16bpc openEXR).
Mip-mapping, what does it mean?
What does it mean? Well, it's an abbreviation from the latin phrase "Multum In Parvo". There, does that help? :) Actually, what it does is take the image and halve it several times and store all those versions of the image in memory. As a rough estimate you can bet on 50% extra memory usage for the mip-mapped version of the image, in addition to the memory usage for that image in the first place - our earlier example OurSquare image at 2.9MB in LightWave would also have about 1.5MB of mip-map added for its final render memory requirement (a colour 8-bit version at roughly 976k will also have a mip-map quota of 1.5MB because the mip-mapping process converts colour images to 24-bit. If however, the image is greyscale, then the mip-map will only be about 490k). Why would it want to do that? If we are dealing with that plaque example I mentioned earlier, there is no point in accessing the whole image for mapping what could be a single pixel on-screen. It makes sense to only look at a 1x1 mipmap for that data because it's much easier on the render engine and more efficient in terms of render time, albeit with a small amount of overhead for creating the mip-maps in the first place. Plus, since mip-maps are created once for an image, it means that they will be referred to in every frame of an animation, and since they are always the same, so will the textured detail in each frame of your animation be. You can globally turn off mip-mapping in the Image Editor to save memory for a single, still image render, but doing so if you are aiming to create an animation can cause problems, unless you want to up your anti-aliasing dramatically - something that adds time, but not a memory cost, to your render.
A final recap
Only use greyscale images for anything than the Color channel for your surface. Don't use JPEG to save images - particularly greyscale ones. Turning off mip-mapping can save memory, but at the expense of render times and possible inconsistencies in animation.
BeeVee 04:43, 24 Jul 2006 (EDT)
