Hello, folks. My client and I are experiencing a very strange issue after making the switch to JSON spritesheets, as created by Texture Packer. We have a video up demonstrating the issue (I recommend viewing at full screen):
There is what my client and I can only describe as a waviness, which is most clearly seen propagating from the character’s left foot at around the 0:10 mark. The strangest thing is that the character appears pixel-perfect when on the right side, where the camera is forced to clamp to a BoxCollider2D. The same behavior is seen with an identical collider on the left. However, as soon as the player moves away from the border such that the camera is scrolling in open space again, the waviness returns.
We had achieved pixel-perfection before, using Point filter mode, POT textures, and a camera size following the formula “resolution height / 2 / 100”, so a 3.6 size for our height of 720 pixels. JSON is the only major change in how the spritesheets are created and imported, although this is forcing a significant restructuring on my end. I now have the SpriteRenderer parented to the player root. Each time the sprite is changed using my custom animation system, the SpriteRenderer is repositioned in order to preserve the relative position from the original sprite, despite cropping from JSON. The movement collider and controller scripts are all on the parent so the sprite maintains an absolute position and plays nicely with Rigidbody physics.
I can’t imagine this restructuring is interfering, but I’m having a tough time telling where this issue is originating, especially given the funky aspect of camera positioning. I’ve had to disable most features, pending a reprocessing of all spritesheets. This is one of relatively few issues holding up a Kickstarter campaign, so if anyone has possible solutions, or anything to point us in the right direction, we would really appreciate it!
Might be easier to see the problem with screenshots of the problem next to original source texture. I can’t say what might be wrong judging by the video.
Just some thoughts though, no mip maps? point filtering? power of two textures (even if sprites broken up aren’t pot thats ok)? How about setting texture format to point through code if there is every changes made to the texture? 1 pixel to 1 unit? Camera set to half screen height (or wait is it height or width… I forgot now)
Anyway if you could post some pics it would help the community really identify what is going on.
Hey, thanks!
We’re not currently using mip maps. We’ve stuck to POT and Point filtering, although I hadn’t considered resetting that through code. (We never change filter type except when experimenting.) Heheh, yeah, I’m pretty it’s half height. We’re doing that at the moment, but further reduced for Pixels To Units (100). Your suggestion of 1 pixel to 1 unit is very intriguing. I researched it quickly, but I’ve seen recommendations to remain at default settings…apparently the Physics system starts freaking out at excessively high values? I still rely on rigidbody movement.
I’ll try producing comparisons if I can, although the sprite is only being stretched horizontally by a pixel or so, making it hard to see except by video. Pixel-perfect and erroneous behaviors are both seen in the video. I know it’s hard to tell, but full screen HD makes it a little easier. When the character is on the right side starting at 0:03, his boots are pixel-perfect, no shifting at all. At around 0:11, the boot on the viewer’s right is stretched horizontally, what must be every cycle of the animation. This effect appears to be only a handful of pixels wide, but travels from right to left across the character.
It’s got to be something with the camera…perhaps the fact that the camera is moving in floating point coordinates, on a sub-pixel level? This other thread instructs to round the camera coordinates to the nearest pixel. I’m currently taking a closer look at the code.
Sounds like your on the right track, maybe only move the camera in one hundredths of a unit, to ensure that pixels aren’t "stretched " when rendering (I’m guessing lol). And yes if your doing physics stuff don’t use the 1 pixel to unit thing, probably would act up with physics. I can’t come up with anything else to check, hopefully someone else could elaborate.
Yeah, I verified a little while ago that the other thread held the solution. It took some fiddling with, until I realized playing in the editor was messing up the way he retrieved the Pixels to Units value. However, it was dead on, and with all the research we’ve done I’m amazed we didn’t stumble upon any mention of this problem (or solution) elsewhere. It looks like we’re ready to finalize our visuals and get a move on. Thanks for your input. 
Awesome! Hope all goes well!