Very large texture problem

I make my own textures. Currently, I am struggling with a project to build a Palace: I have made a facade which has some transparencies for windows, and a composite of other textures, most of which I have scanned at 900 pixels per sq inch (lower scanning is too blurry). And yes, I have done this with the Sistine Chapel ceiling for the ballroom, and it comes out just fine as a jpg!
Once I have created the pixel-perfect facade in Photodeluxe (PSD), I have to transfer it to Gimp to change it into a tga to upload to SL. An example facade is 31 KB in PSD, and changes to 41 KB in tga. The tga file is much to large to upload to SL, so I progressively shrink it to around 300 or even 150mm in size so that it will be accepted by SL. This takes a long time and much logging off and on again. When I finally do get it small enough to be uploaded, (between 1,500 and 900 KB) it has shrunk its pixel count from 900 psi to a measly 72 psi. This makes it all blurry when I paste it onto the mega prim I use for the facade.
I don't understand where in the process it plunges in psi count down to something so minimal and unsatisfactory.
I use transparencies very sparingly, as I know they cause lag, and the megaprims are used judiciously too. But after hours of work on a facade it is driving me mad to end up with something looking so shoddy.
Please advise me.

Best wishes from Ainee Kohime

SL (like all 3D programs) have their limitations, I think the only thing you could do would be to cut the single texture up into smaller ones, and upload them separately, then change your build so you are applying the texture to multiple prims rather than one.


http://www.secondscripter.com

Count pixel width and height in in pixel and not on metric units and resolutions.
Youre not printing it, but porting it into a game.

Your first conversion should result in a power of 2^x pixel width and height for the full Image, like 8192x4096 from your source photo.
That highres image can then easily be adjusted, edited into a tiling texture or split into other powers of 2^x or blend/mixed with other textures.
Then all downscalings are as lossless as possible, down to 1024x1024 or smaller powers of 2^x , wich are resulutions that sl uses.
Keep the larger version as a source backup for later edits.

If you put your texture on one huge prim it will either have many repeats, should be tiling smoothly for that.
Or it is just more stretchend on a larger prim than on many smaller prims, and you might think about splitting your non-tiling-texture into multipme texture-parts to put on multiple prims.

41kb in TGA is too large.

I would recommend reading this thread which will answer most if not all of your questions regarding pixel count, file size etc.

/109/e6/150360/1.html

Edit: A snippet from this thread explains one of your problems;

ALLOWABLE TEXTURE SIZES & RESPECTIVE MEMORY USAGES

OpenGL, the graphics language in which SL is written, requires the heights and widths of textures to be measurable in powers of two. SL has further restrictions of its own in order to keep texture sizes reasonable, and to ensure compatibility with as many video card makes and models as possible. The allowable dimensions are all powers of two from 8 to 1024. (That means 8, 16, 32, 64, 128, 256, 512, and 1024, nothing else.)

41kb is not a power of 2.

As others already stated, the only thing SL cares about is pixel count in each direction, and it MUST be in "power of two" multiples.

I recently did a huge texture for a full-sized football field. It's detailed enough to see the blades of grass...

The trick is to break the texture up into panels of no more than 1024 x 1024 pixels before importing.

In my case, the football field required eight images at 1024 x 1024 to create the field from the back of one end zone to the back of the other, and one more texture to tile around that for the unmarked rim of grass between the playing field and the stadium seats.

I created the image in Photoshop, as a 4096 pixel wide by 2048 pixel high image. I then placed guide lines as needed to slice that up into 1024 x 1024 pixel squares, copied and pasted the eight squares into their own 1024 x 1024 image files, and imported each into SL as a seperate image. The plain grass was created as a seperate 1024 x 1024 image, which I made first, and then painted the chalk lines and conference markings onto.

Once I had the images importer into SL as 24-bit TGA images, I tiled them across a 3 x 3 array of 10 M prims, so that each 1024 x 1024 image became 30 M wide by 30 M long in SL. (For your walls with windows, you could use 32-bit TGA)

You can look at that football field un the "RUCE 3" sim. It was built for Rutgers University.

To look at buildings that have alpha-mapped wall textures, take a look at how I did the college campus in the "HHP at UH" sim, for the University of Houston. Most of the wall textures there are made in panels that are 512 x 256 or 1024 x 512 pixels in size.

One more thing... Since the limit on texture size is 1024 x 1024 pixels, I wouldn't ever use a megaprim that is any larger than 50 M x 50 M for any building that needs serious detail with a non-repeating texture. Take a look at the three sky platforms that are above the football stadium in RUCE 3. There is a teleporter desk near the East end zone to get up to them. They each use two 50 x 50 megaprims, with one texture each. So one 1024 x 1024 texture streached over a 50 M square means each pixel is 4.88 cm across in SL. That is about half the width of the palm of an adult's hand! (A little smaller when compared to an avatar's hand, since most avatars are about 1.25 x the size of real-world Humans.)

Now compare the lack of detail on those platforms to what I got on the ground, using normal 10 x 10 prims and tiling a 1024 x 1024 texture across three prims in each direction. That came out a bit sharper, at 2.92 cm in-world for each pixel in the original art.

A 1024 x 1024 texture on a 10 M prim comes out to pixels that are 0.97 cm across, or less than the width of an adult's smallest fingertip. Which, as architectural detail goes, is STILL pretty darned coarse!

If your palace has wall and window patterns that repeat, you may be able to get away with larger megaprims that repeat the texture across the prim. But aside from some modern architecture like skyscrapers, you really won't be able to do that very much.

Bottom line: If details matter, don't use the megaprims. Spend a few more prims and use normal prims, so your textures don't get smeared across such a large surface.

I'll give it my best shot. There's a lot to change here.



A couple things here. First, I assume you mean 900 pixels per inch, not per square inch. 900 per square inch would only be 30 per inch, which is extremely low.

So you know, square inches are not usually the units of measurement for this sort of thing. It's generally just inches. 900 dpi would put 810,000 dots in every square inch.

Second, scanning at 900 dpi is almost always overkill. Most "high quality" prints are done at 300 or 600 dpi (which, if you want to get into square inches, means 90,000 or 360,000). Scanning at anything above that is usually pointless.

The only reason you'd ever need to go higher would be if you're scanning negatives or something, and that's only because negatives are small. Sometimes it's acceptable to scan a photograph at high resolution, if your intent is to reprint it at several times its original size. But be prepared in those cases to do a lot of cleanup work, because when your dot size is that small, you end up picking up extra-image details like the grain of the paper, tiny specs of dust, fibers, etc. All that stuff would then need to be removed digitally before the image would be suitable for reprint.

When scanning for texturing purposes, there's almost never any no need to go that high, ever. The only exception would be if you wanted to make a large texture from scanning something very, very small. For example, if you want to produce a 1024x1024 texture from a scanned penny, then you might want to go as high as about 1365 dpi, since a penny is only 3/4 of an inch across. (3/4 of 1365 is 1024.)

For more normal operations, like making textures from photographs, there's no point in scanning at ultra-high resolution. When I scan a photo, I usually do it at 300 dpi, just to create an archive copy, since that's the resolution I'd be most likely to reprint it at if I ever need to. Then, to make it into a texture, I'll downsize it appropriately by its pixel count, not by its dpi or ppi settings.

As others have already mentioned in this thread dpi (or ppi) is absolutely meaningless for textures. Your video card has no idea what an inch is. All that matters, as far as size goes, is the number of pixels in the image. How many of them might happen to fit into an inch only matters for print. I'd strongly encourage you to forget all about things like inches, centimeters, dpi, ppi, etc., and instead focus just on pixel counts.


No matter how good or bad it might look being sourced from a JPEG, I can promise you it would look better if it were sourced from any of the other three usable formats. JPEG is lossy; the others are not. By definition, TGA, BMP, and PNG imagery will always be higher quality than JPEG imagery.


That's not really possible. A 32-bit TGA file has 4 bytes of file size for every pixel of canvas size (32 bits = 4 bytes). In order to be just 41 kilobytes, it would have to have only about 10,000 pixels in it. If the image were square, that would mean it would be just 100x100 pixels.

If you scanned at 900 dpi, then to create a 100x100 image, your source would have had to have been just 1/3 of an inch wide by 1/3 of an inch tall. You're not scanning postage stamps or something, are you?

Did you perhaps mean 41 MB? If my math is right, at 32 bits per pixel, a 900 dpi scan would yield a 41MB TGA file if the source image were roughly 7.25x7.25 inches. That sounds about right for a photograph.



Yes, it is, but not for the reason you seem to be thinking. It's not the file size that's relevant; it's the canvas size. The largest size SL can use is 1024x1024 pixels. By the sound of it, your images are at least 10 times that size.


Again, forget about things like millimeters. All that matters is the number of pixels.



I can see how it might take a long time to resize such large imagery if your computer isn't the fastest, but I can't imagine why it would require you to log on and off repeatedly. Just size your image appropriately, and upload it, end of story. What am I missing?



Two things:

First, it's "ppi", pixels per inch, not "psi". I assume by "psi", you meant pixels per square inch, which as I said earlier, is not the way these things are typically measured.

Second, as I've said a few times now, the question of how many pixels fit into a real world inch is completely meaningless for textures. Again, what's important is the number of pixels you have, not how many might or might not happen to fit in an inch if you were to print the thing.


This is why you don't see too many facades made out of just a single prim. There's not generally enough pixels available in a single texture to create enough detail for anything with that much complexity to it.

Additionally, in my observation megaprims have some rendering issues. Textures on them do not seem to render quite as well as they do on regular prims. I'm not sure why, technically, this should be, but it does appear to be the case.

If you put something like a 256x256 on a reguar prim, and zoom in on it so it fills the screen, you'll be viewing the texture at somewhere around 16-25 times its actual size, depending on how big your screen is. In many programs, that would be more than enough for things to start to look terrible, but SL happens to be really, really good at this sort of thing, so that blown up texture ends up looking just great. But now, put that same texture on a large megaprim, and zoom your view out so it's the same apparent size as that regular prim just was a second ago. You'll see that the texture on the megaprim will look considerably more pixelated than it did on the regular prim, even though it's occupying the same amount of pixels on-screen either way. It seems that whatever interpolation scheme SL uses for scaled high quality texture rendering starts to fail when the polygons get too large. Again, I don't know why this should be, but it is.

Another problem is that since you haven't been sizing your textures properly in powers of two, you're dealing with SL's resize-upon-upload process, which isn't that great. When you resize your images properly in your paint program ahead of time, rather than letting the uploader do it for you after the fact, you'll always get better looking results.




Good news, it's not "the process" that's the problem. It's just YOUR process that needs improvement. It's nothing that can't be fixed.



Transparency is the least of your problems. The shear size of your textures will cause more lag than any degree of transparency ever could. Remember, the average video card can only precess a few hundred megabytes worth of data at a time. It doesn't take all that many 1024x1024's to make one choke.

The single biggest reason SL runs as slowly as it does is because most people use textures that are way too big. To keep things running smoothly, keep your textures as small as possible, always. In most cases, 256x256 is as big as you need to go. Rarely go as high as 512x512. 1024x1024 should only be used under extenuating circumstances. If any more than 5% of your textures are 1024x1024, you're doing something wrong.

That said, it is true that over-use of transparency will cause problems, so it's good that you're keeping things reasonable in that regard. Now you just need to be equally responsible about your texture sizes, and you'll be all set.

Read the sticky on sizes and file formats, at the top of the forum. It's need-to-know information.

Chosen,

with you mentioning this can I just add this question as I have seen you answer this indirectly on other threads but it is stil not clear. (to me anyway)

I have recently designed a texture that has 20 or so textures on it that can be used separately. I had the choice of uploading 20 individual textures at different sizes or grouping them altogether and uploading one 1024x1024 texture.

Without doubt the textures will be used in one item/object/build so my question is;

Is it better to use 20 textures or so in one texture that will be used in the same object/item/build or should I use individual textures?

My understanding is from your previous posts is that one 1024x1024 texture consisting of all textures is far friendlier/not so laggy than 20 individual textures.

You've already received the technical advice.

I'll add to that that you shouldn't become obsessed with bigger-is-better in Second Life.

Do an experiment. Build two 10 m x 10 m square prims to be your walls. In your graphics program, make a 1024 x 1024 texture for it. Export it in a 1024 x 1024 TGA version, and then a 512 x 512 TGA version. Put your big texture on one wall, and your smaller texture on another wall. Compare them side by side.

Do you notice a difference? The main difference that you probably notice is that the bigger texture takes a lot longer to load. Once both textures are loaded, they probably look identical.

Bigger sometimes means eating more computer resources with no noticeable benefit.

Amity

Are you answering my question?

Sorry, no, my post was directed to the OP. I didn't make that clear.

I happen to know the answer to your question, though.

One 1024 x 1024 texture is more efficient than four 512 x 512 textures.

The file size between the one 1024 x 1024 and the four 512 x 512 texuters is the same. However, four textures require four requests to the asset server; one texture only requires one hit to the asset server. (Maybe there are other reasons as well; that's just the reason I happen to know.)

And you can play out the math beyond that. For example, one 1024 x 1024 is the same file size as sixteen 256 x 256 textures, but only one asset-server hit compared to sixteen.

Thanks Amity for yor reply,

that helps me, reading from what Chosen had previously mentioned in other posts implied much the same but I cannot find the exact thread.

I assumed it would be better than 20 different textures at various sizes as once the texture/UUID had been uploaded then the server only has to look for one and not 20.

Fairly common sense I think but I am totally useless myself trying to explain technical terms and sometimes having to understand them.

Amity beat me to it.

Yup, sheeting textures like that is a great thing to do. The only reason not to do it would be if all the images were not going to be used in the same scene. As long they're all being used together, one asset is more efficient than 20.

Crikey, thank you everyone! After a year, i still have so much to learn!

My biggest facade texture came out as 1024x512, and i agree that the blurr may be a megaprim rendition issue. The Sistine Chapel was 1024x1024, so now i need to work out how to make the facade texture bigger... Not sure how to make textures to specific sizes like that, as i only see that size in SL when i have uploaded them.

I did try to resize my images in Adobe photodeluxe, instead of in Gimp, which gave better results, but SL will not accept most of the new ones, they are too big. Photodeluxe keeps crashing just as i have finished a texture, so i am weary of it.

I bought Photoshop yesterday and two books on how to use it, i hope that i can learn to do things better there.

Btw, i remade my facade in standard prims, and it needed 85. That is one of four walls, too primmy for me. Doing it with one phantom mega prim has to be better, even with some blurr. I can see a way to add a few prims to give the desired effect, though, so thank you for helping me to think this through!

Best wishes from Ainee kohime