Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

how do i make multi image without lines

Rick Brock
Registered User
Join date: 4 Jun 2006
Posts: 6
07-23-2006 07:14
Ok here is the situation without i use generally 1200-768 images broken down in psp9 into as many at 20+ individual images now since last patch i am assuming no mater how i break it down no matter the size the way u bend the texture it has lines like the texture wasnt cut properly or objects arent joined right wth am i doing wrong mind u exact same image same way on my own property worked perfectly pre this update same images new property suddenly have theese stupid looking lines at joints destroying the textures quality
help in any form would be greatly appretiated
Chosen Few
Alpha Channel Slave
Join date: 16 Jan 2004
Posts: 7,496
07-23-2006 08:41
Instead of slicing your image into multiple pieces in PSP, upload the whole thing in one piece, and then simply use repeat and offset settings in SL to determine which section of it to show on each prim.

For example, if you wanted to do 20 sections, as you mentioned, you're probably going to arrange your slicing into a 4x5 configuration. That's easy. Simply set the repeats per face on each prim to .20 in one direction (for 5 slices) and .25 in the other direction (for 4 slices). Then simply offset the texture on each surface by consectuve incriments of .20 and .25, and you'll piece together the entire image. Not only will this eliminate any visible seams, but it will also make the whole process much easier on the server since there's only one call to download an asset (the texture), not 20. Not to mention, you'll only have to pay one upload fee instead of 20.

A couple of additional tips:

First, it's not a good idea to use numbers like 1200 or 768 for textures. OpenGL requires that textures be measured in powers of 2 in each dimension. Use anythng else, and SL will resize the image for you at the time of upload, and the results are not always pretty. Usually there's a noticeable loss of quality.

To keep SL from auto-resizing your work, always use any of the following numbers for the height and width of your canvas: 32, 64, 128, 256, 512, 1024, or 2048.

Second, before you upload large textures, make absolutely certain they really need to be that big. Poor texture size management is the single biggest source of lag in SL. Wanna know why normal games on your computer get like 60+ FPS while SL gets 10-15? The biggest reason is that those games are optimized to keep the texture load on your video card under a couple hundred megabytes. All the textures in those games are deliberately kept very tiny. SL, on the other hand, being a user-created environment is not optimized at all. People do silly things like put a 2048x2048 texture on a 2-meter sign, when a 128x128 would have worked just fine.

SL is better at taking small images and blowing them up to full screen size than pretty much any program I've ever seen. To see what I mean, rez a cube, and put a medium sized texture on it, say a 256x256. Now zoom in on it so it fills your screen. If your SL window is 1024 pixels wide, you're now viewing that texture at 16 times its normal size, and it still looks just as good. This is one of the areas where SL really shines.

Now, consider that every 2048x2048 sized texture consumes a whopping 16MB or 12MB of texture memory (16 with transparency, 12 without), every 1024x1024 consumes 4MB or 3MB, and every 512x512 consumes 1MB or 768KB. Multiply that by a few hundred textures in viewing distance, and it's pretty easy to see why video cards choke. In poorly managed areas in SL, there can be tens or hundreds of gigabytes worth of texture data on the screen, while video cards can only handle up to a couple hundred megabytes or so.

More reasonably sized textures, on the other hand, barely consume much texture memory at all. A 256x256 only uses 256KB or 192KB, and a 128x128 uses only 64KB or 48KB.

Always consider when determining ideal texture size how much screen real-estate does this image actually need. In other words, what portion of most people's screens will the object occupy when they view it?

If it's something that needs to be sliced into 20 sections like what you're talking about, then chances are the object it's going on will be something like 40-50M wide. In that case, I'd imagine most people won't be viewing the whole thing at once. If it's a 50M wide wall, for example, that people will primarily be standing next to, not viewing from a distance, then they're only going to see part of the texture at any given time. In that case, it's reasonable to make the texure equal to or larger than average screen size, maybe 1024x1024. However, if people are like to be seeing the whole thing at once, there's absolutely no way it's going to require that many pixels onscreen. 256x256 or 512x512 would work just fine.

Always err on the side of smallness with texturing. There's usually almost no benefit in going big. The rule of thumb I usually recommend to people is about 75% of your textures should always be 256x256 or smaller, about 20% should be 512x512, and the remaining 5% should be 1024x1024 or 2048x2048.

Hope that info helps. Good luck. :)
_____________________
.

Land now available for rent in Indigo. Low rates. Quiet, low-lag mainland sim with good neighbors. IM me in-world if you're interested.
Rick Brock
Registered User
Join date: 4 Jun 2006
Posts: 6
07-23-2006 09:49
i probably didnt explain completely i start with a image that large than slice it in psp so when i upload it in 20 sections it isnt ugly from the sl resize ty for the info will give it a shot on my next project and see if just resising the image repeats works rather than uploading a monster immage in 20 pieces
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
07-23-2006 17:52
the load your making your video card process is the same as 1 large image, and makes 20 request's to the asset server, which is drasticly slower (ask find fetch send render for each image) altho you may not notice it untill your in a heavly active sim