First off, accelerator offsets. I am storing offsets when a certain file awakes. everything works perfectly when running it in Unity via the Unity remote. Load it onto my phone and there are no offsets stored, or the offsets are saved as zero as it is obviously operating as if everything was neutral.
Secondly, I have a texture of 2048x512 I am trying to use on a large plane. Since the largest texture the iPhone hardware can handle is 1024x1024, I split these up into two textures and put them on planes that should be intersected perfectly. However there is a flickering line between these textures that is quite evident, yet I must figure out a way to remove this. Is it possible? Thanks for any help offered.
I can confirm I’ve had the same problem on one of my prototype games. Although, I haven’t worked out a solution as the prototype never got too far into development.
Are the planes actually intersecting, or they just have their edges lined up against one another? Is the flickering line showing through the color behind the planes, or some random color from the texture maps?
If these are compressed textures, I’m not sure that these settings will make a difference. Since PVRTC shares data across adjacent blocks, don’t blocks on the edge of the texture pull from the block on the opposite edge?
Hi Adam. My original wording wasn’t clear enough. The edges are lined up, they should not be intersecting. The flickering color appears to be white and that’s it. And yes I am using PVRTC.
Since I can’t see the problem, I am guessing you have one of two things:
You are seeing whatever is behind the planes, as though the edges are not precisely butting up against each other.
The “white” is because the texture has lighter colored pixels on the side opposite the seam. What you are seeing is the result of compression, because block lined up with the seam is sharing information with the block on the opposite side of the texture. In the example picture, let’s assume the black line is a seam in the plane where you are using two separate textures. The pixels in the red texture that are up against the seam will become a little lighter with compression because they are sharing data with the blocks containing the white pixels on the opposite side. You can see, if the red texture were tiling (translucent/pink) that these parts would be adjacent and sharing data.
I am slightly confused by your answer, other than to gather that you’re saying the line is the result of compression. However this visible line “flickers” as the camera moves. It doesn’t look like a compression error per se. Perhaps that is part of it (or maybe all of it) but I am just wondering if it is “fixable.”
If it is flickering, it is most likely an actual physical separation (so you are seeing whatever is behind the planes). It could be a floating point precision problem, especially if you have scaling applied to the planes.
Flickering can be a consequence of compression, but I usually only see this type of flickering along the edges of a model where the normal for that particular pixel is approximately 90 degrees from the camera vector (so dot product is about 0). I haven’t seen this type of flickering on a plane though unless it is at a really low angle, so I’m guessing you’re seeing the first type.
