Texture Size, Pixel Counts, Video Memory, and File Formats

No. A 32-bit texture, with alpha, takes more video ram than a 24-bit opaque texture of the same pixel dimensions.

Yes. Each texture that you can see at once requires more video ram to see it all at the same time, without other textures reverting to fuzzy or grey areas.

To add to what Ceera already said, check the chart in the thread starter here, Nefertiti. It shows how much video memory every possible texture size consumes. Not the ones with alpha channels always take 33% more than the same size ones without.


Yes. Reuse textures as much as possible.

Thanks.

I can't do some things without transparency, so I'll have to work on minimizing texture size and reusing them as much as possible.

*watches the stars whirling around his head* Ok now I'm confused. So say you are trying to make a thinc Book and you need clean resolute images, which format is best.

Did you read the original post? I realize there's a lot of information in it, so it might be a little overwhelming if you're new to all this, but it's worth the read. Here's the relevant portion to your question:


Got it?

I only asked because it says TGA's are a large file size. If I make a book with a lot of pages, then I'm corcerned it will take forever and a day to load. Never mind, I'll figure something out. I got it.

The file size doesn't matter; only the image resolution and bits per pixel. The file size doesn't matter much because regardless of what format you use when uploading, they all get converted to the same format inside SL.

With TGA, you can have 24 or 32 bits. You only need 32 bits if you need transparency.

To optimize your book, choose an image resolution (number of pixels down and across) that's as low as possible and yet where the text and images are still clear, and remember that in SL they'll be a little less clear due to not looking straight on most of the time.

You might want to get a scripter to help and write a script to preload the images, so the reader doesn't have to wait after turning each page for that image to pop up.

As Leajeff said, the source file size is irrelevant. Everything in SL becomes a JPEG2000 the moment its uploaded. Whether you're sourcing from a TGA, a BMP, or a JPEG, the JPEG2000 will come out exactly the same size. Sorry if that wasn't clear in the original post.

Hi All, got a question I can't seem to find a simple answer or chart for.

What is the Pixel to Prim ratio? And or, what is the Lines Per Meter?

As in the target resolution.. kind of like for printers vs. screen... I know that to print something on paper in RL images are set to anything above 300 dots per inch. Which is a loose estimation... but usually in the past you call the press and ask.

If I have a prim that is 1.5m x 10m x 2m.. and I want the 1.5x10 to have the absolute best image possible aside having the best compression.

Is there a formula? Is it as simple as having a 5.12 x 5.12 x 5.12 box and I output a 512 x 512 square pixel @ 72 dpi targa file from photoshop? Would it look better if it was 512x512 @ 144 dpi?

Like LCD monitors have a specific native resolution at a specific dpi.. however which way you go outside that, the image get fuzzy. What is SL's native graphic resolution?

Any input here would be appreciated!

{ a }

Augustum, I think the only answer to your question is, how close are you looking at the object?

There may be some maximum resolution for a tiny object zoomed way close, but as a jeweler I texture and study tiny objects and I don't remember noticing this.

Barring that, there is no equivalent to a DPI for SL. There is a DPI governing screen resolution, but that is subject to both size and distance (and angle) of the surface you're looking at. Of course, that provides reasonable guidance for texturing when building. I believe that SL calculates using a 600x800 grid. Therefore, a texture that is intended to be looked at en-toto (like a page of text) shouldn't need to be higher resolution than 512x512 or maybe 1024x1024. However, an exquisite art work that someone might move close to and inspect might deserve a higher resolution (if supported). And the texture for a single brick certainly needn't be so high, that would just be a waste of resolution. (Not that anyone would normally use one prim per brick, but just as an example.)

In general, builders tend to use higher resolutions than necessary, leading to lag. My suggestion is try different resolutions and see what the results are for your application and adjust accordingly.

Thanks Learjeff, good input!

Now that I have read, and then reread what I typed this morning (pre coffee) I think I have a more exact question to ask.

I have a face of a prim that is 2m x 5m - what is the pixel dimensions of that face? So if I make the image width 512 px and then the height would be...? If I "have" to stick to the size constraints of uploaded images.. and 2 is 40% of 5.. do I make the image 512x256 (50%) and then stretch the graphic to be then squashed accordingly?

I have gotten kind of comfortable looking at the image and stretch/pull the prim to match it... and since we are restricted to 8,16,32,64,128,etc,etc,etc.. how can I create a graphic that is to match the prim.. ie. 512x512 is a "meter" x "meter" dimension face/prim

I may be missing something.. any thoughts?

The pixel dimensions of any face depends on how far away you're viewing it.

If you're far enough away, it's one pixel (in theory -- in practice such small objects usually get clipped, I imagine). If you're close enough, a 1CM sqare of it could occupy your whole screen (calculated in 600x800 resolution, if I understand what I saw elsewhere on this forum).

This may take some time, because you have a mental image of what SL is that is not correct, and revising mental models often takes a bit of thinking.

SL models reality as mathematically defined "primitives", such as a cube with a given size and textures. These prims are further broken down into triangles, which the video card understands to some extent. These triangles don't even have a pixel count per se. The triangle is transformed (rotated and sized) corresponding to its distance and orientation. The video card maps the texture to the triangle. At this point pixels finally come into the picture. That's far too late for your questions to be meaningful as stated.

Regards,
Jeff

Ah, finally on reading your question better I understand your problem, and the solution is simple.

Don't worry about pixels so much, but rather concentrate on aspect ratios.

The aspect ratio of an image is the height-to-width ratio. For example, a typical computer screen has a 3x4 screen size, meaning an aspect ratio of 0.75.

If you have an image that looks correct and you want to apply it to an object you're building or can modify, find out what the pixel dimensions are and calculate the aspect ratio. Then adjust your object to the same aspect ratio.

Of course, since my mental math is bad, I use an easier way. For example, I tend to crop images to handy sizes like 1x1, 1x2, 3x4, 5x7, etc. When I build an object to put it on, I make the object the same ratio in meters or tenths of a meter and then stretch it to the size I really want (using the white handles, which preserve shape). So, for a 5x7 image, I'll make the box 0.5 M high and 0.7M wide, and then hold control key and drag a white handle until it's the size I want. Or is it shift-control? Well, whichever combination gives me the stretch handles.

No doubt there are also guidelines to tune the image's exact size for the best conversion on upload to SL. However, I tend to simply crop the image to what I want, shrink it if it's more pixels than I want for efficiency (shrinking it so that the smallest dimension is a power of 2), and just let the upload conversion software do what it thinks is best for the rest. For images like text in a page in a book I'd probably want to be more careful to pick a 2x1 aspect ratio and size the image to exactly what SL would use before uploading. But for normal purposes I find this isn't necessary.

Awesome, great input.. Thanks Learjeff! And Thank you Chosen!!

Hi people, I am new in SL, I am graphic designer but for me is new the 3D world and I have some questions that still confuses me, if u can help i will apreciate it.

I am making skins and later i will do some clothes, my problems is about correct sizes of textures, I read and read and still I am confused. I download some templates and all are in diferent sizes, so I would like to know wich is correct, for example some are in 1024x1024 with 150 dpi, another 1024x1024 72dpi, and another 512x512 72 dpi. Well fisrt question is if its important the dpi, these are computer graphics and i suppose that 72dpi is enough, by the other side i read some times that maxium resolution of the game is 512x512, so whats the point working on 1024x1024?

I always lose details when i download the texture in SL, and SLCP shows me more details in skin textures than SL, so anyway to do realistic textures? Everytime i download the skins in SL it sees more plain, so I am seeing that the effort of do details in the face is not worth and its more work of highlights and shadows.

In the end wich is the correct size to upload the textures? 512x512 72dpi?

Thanks all

Don't worry about DPI at all. That only matters for print. It has no meaning in 3D graphics whatsoever. A pixel is a pixel is a pixel.

As for sizing, your assumption in your final question is correct. Upload clothing and skin textures at 512x512. Other sizes can be used for texturing objects, but avatar textures should always be 512x512.

The reason some of the templates are larger is simply because it's easier to work at larger sizes, especially for things like matching seams. If your seam mismatched by a pixel or two at 1024, it's not likely to show when you downsize to 512. But if you're working directly at 512 and you're off by a pixel, you're definitely gonna see it. With this in mind, many skin makers work at 3000x3000 or larger, and then they downsize the output before upload. Yes, detail is lost during the downsizing, but the results still tend to look a lot better than the results of working at 512 from start to finish.

Thanks a lot, i had this doubt about dpi, i supposed that was 72dpi, well i wonder how many people save the works in 150 dpi, I tested and size changes, a .tga with 512x512 150 dpi occuped me 1'1MB and with 72 dpi 400k

I will do the base of the skin at 1024 and once time resized i will do the details, I think will be the best way to not loose details.

If the file size changed, you must have lost pixels. When you changed the DPI, did you remember to uncheck Resample Image? If not, then when you changed it from 150 to 72, you eliminated almost 60% of the pixels in the image, so of course the file size got about 60% smaller. A 512x512 TGA at 32-bit will ALWAYS be exactly 1MB, and at 24-bit it will ALWAYS be exactly 768K (barring any compression, of course).

If you want to know why, here's the simple math (which was also explained in the original post here):

● There are 8 bits per pixel in each channel.
● 8 bits times 3 channels (RGB) equals 24 bits per pixel.
● 24 bits times 512 x 512 = 6,291,456 bits in the whole image.
● 6,291,456 bits divided by 8 bits in every byte equals 786,432 bytes.
● 786,432 bytes divided by 1024 bytes in every kilobyte equals precisely 768 kilobytes.

DPI plays no part in that equation, and so has no bearing on file size whatsoever. A file doesn't know what an inch is. What matters is the number of pixels, and the number of bits in each one. That's it.


Of course, another possibility is that your second image was compressed, and your first one wasn't, but I find that unlikely. First, it's pretty hard to turn compression on in a TGA without knowing it, and second, it would be a stellar coincidence for the math to work out so neatly. 72 is roughly 40% of 150, and 400K is roughly 40% of 1MB, so that adds up perfectly. For compression to knock out exactly that same amount would be pretty tough to pull off, although it is certainly possible.



Just make sure when you downsize this time, that you DO have Resample Image turned on. Otherwise you're just gonna change the DPI without actually eliminating pixels.

In situations where you want to preserve your pixel count (like you should have had in your experiment), keep Resample Image turned off. In situations where you want to add or remove pixels keep Resample Image turned on.

Ops, u are right, was my error, i did the test too fast

Thanks for all! Soon i will post how is going my 1st skin

Great, Desidelia. Looking forward to seeing how you make out.

Is there a function to check if a texture has fully loaded? I want to run a slide show that shows a sequence of images, which are loaded using llSetTexture. Is there a way to verify that texture 1 has fully loaded before moving on to texture 2, then to 3, etc?

I have a time delay built into the script, but because each viewer's lag is unique, I was really hoping there is a built-in function so that I could pause the script, confirm the texture has fully loaded, then restart the script.

This really belongs in a separate thread, not in this one, but in any case, the answer to your question is no. Whether or not a texture has "loaded" will vary from user to user. You and your friend could be looking at the exact same object and while the textures might be clear to you, they could be blurry to your friend at the same time, or vise versa. The server sends all the data to each user as fast as it can, but how long it takes that data to be received and displayed by each client machine depends on all kinds of chaotic factors that are well beyond anyone's control.

If you don't mind investing a few extra prims, it's sometimes a good idea to hide a few small cubes with the textures on display around the view screen, and use a script to set the cubes to 100% alpha. That way, the user technically has "seen" the textures (even though the cubes are invisible) before the slideshow gets to them, so they're already cached, allowing each slide to "load" instantly.

Also, I think there are ways to force a precache via script without the extra prims, but I don't know how to do it, and from what I understand, it doesn't always work.

Thanks Chosen Few. Your 'cube' suggestion is a good idea.

another trick along the same line is to hollow out the display screen and set the textures on the inside of the cut, and giving more time to load

you can also use the edges and back of the prims to load up even more, altho doing that you have to keep ascetics in mind

After experimenting, I found it best to use multiple screens, and toggle the alpha values. So while the current image is showing on screen 1, I load the next image onto screen 2. When screen 1 viewing is complete, set screen 2's alpha to 1, and screen 1's alpha to 0. Cycle through the images this way. There's a sleep of about 5 seconds between images. Seems to work pretty well with no lag.