Texture repeat rounding issues

I'm a big fan of putting a whole lot of textures used for the same object in a single 1024x1024 block. I'm a perfectionist in aligning them well, and I do a lot of messing with the offsets and repeats per face.

However, the dang repeats always round off to the nearest tenth. Often a little bit of one texture (or a dark border I use within the sheet) will bleed onto the side. Is there any way to get around this or cheat the system as with prim torture? I thought I'd heard something about a script solution at one time. It's annoying, because I know that the engine can handle thousandths...it looks just fine until I tab off of the repeat, when it jumps back to the nearest hundredth.

Sorry, but SL just isn't up to being that precise. Perhaps a script can do it, but the building tools can't. and I suspect the rendering engine will also have rounding errors, even if you attempt to do an elegant scripted solution.

I allow a certain amount of 'bleed' around any texture that I want to use on a texture sheet. If the adjacent texture isn't the same color at that edge, then I slice up my repeats with thin strips of 'unused' texture area between each one. For a simplified example, instead of using 4 textures on one sheet and exactly 0.5000 repeats, plan the texture so what you need uses a different offset and a repeat of 0.45...

Haven't worked out the exact math, but you get the idea, I hope.

I played around for an afternoon with using a script to precision tile across 30 panels.

Here's a link to some screenshots and my thoughts about the process, as well as a YouTube video (which looks best if you expand it to a larger window.)

I think setting the parameters by script allow finer control -- it appeared to be perfectly precise.

Thanks, guess I'll just be more careful with my textures from now on. The hard part is knowing where a problem area is going to be until you start texturing, and I'd rather fit more textures on one sheet that bleed everywhere just to be safe. Ah well.

Hmm, I've not actually done a proper test, but I had assumed the texture precision problem is the same as for other prim parameters - that the client allows you to type in, and displays properly, information at a greater precision than is actually sent to the server. The way to test it is get something lined up perfectly, teleport away and then come back and see if it's snapped to something bad or not.

It's also possible that certain fractions will work perfectly, while others fail. Things involving 2s and 5s have always worked pretty well for me in prims.