ReadPixels malfunctions on certain Android devices.

So I'm having a huge confusing issue with my Unity project. I'm creating dynamic thumbnail textures of the scene using ReadPixels and save it using EncodeToPng. Works great on PC, works great on iOS devices, works great on MY own Android device.

However on some Android devices the texture generated is a garbled mess.

Here's what the thumbnail should look like


Here's what certain Android devices generate


I can't find ANY other posts about this or what could be causing this, and even after striping down my code as much as I could I'm still getting these bad textures. I'm at my wits end here. Any ideas?!

 

Using 3.5.7f6, Android basic
I didn't know if this was a Unity bug, so I haven't made a bug case or submitted anything yet.

While it's not directly related, I should probably also mention while I said it works fine on iOS I have to deliberately disable anti-aliasing in the quality settings for my iOS build otherwise the generated texture ends up black.

 

HTC® One S phone and LG-VS840 phone
If this is indeed a bug and fix is required, is there any chance of this sort of fix coming for 3.5+, or am I going to need to update to 4.0?

 

These kind of artifacts are created if you map an array of pixels into a texture that is narrower than the data in the array. In your case the size difference seems to be 31 pixels in the horizontal dimension.

Also, the content does not seem to match the thumbnail you presented (some areas are too bright, apparently no/different border).

Is there a possibility that the pixel size of your virtual camera does not match a) the size you assigned to your texture b) the dimensions you write to your PNG? Also double-check aspect ratios of cameras and textures, and camera viewport vs. screen size. Is there any power-of-two scaling enforced? What are the actual screen resolutions of your individual Android devices?

For debugging purposes, make the texture 31 pixels wider than your ReadPixels command. If you do that, do you recognize the resulting image?

 

Note the image you uploaded is 543x543 pixels, which is 31 pixels larger than 512. Also, the black border on the right side is 31 pixels wide.

Investigate where the 543 comes from.

 

In my regular procedure the captured texture gets resized to 256x256. The garbled version is larger because I saved that thumbnail example after stripping out as much things as possible to debug (like the resizing). The garbling does indeed still happen after being resized to 256x256.

The garbled texture is NOT an exact representation of the top image, mostly because it's meant to be a snapshot of what's in the view currently and positioning/lighting changes.

 

So far you did not indicate at which resolution you are actually trying to grab the texture. Also, please investigate all the other points in my two responses, there are reasons I mentioned them.

Also, if for some reason you're trying to grab non-power-of-two sized textures, try power-of-twos instead; some devices might be unable to handle non-power-of-two requests.

 

Fair enough, I'll investigate later this evening after work and report my findings.

 

If I had to guess, I'd say you create a 543x543 texture, but your ReadPixels only grabs a 512x512 area (although you apparently do request 543x543) and dumps it in the larger texture, leaving a black border and thus an image that's too narrow.

 

So what actually happens is I have a un-rendered cube in the scene that is always guaranteed to be within the boundaries of the screen. I get the co-ordinates of its four corners, convert that to a Rect and use that to capture what is currently within the boundaries of the Rect. Since every device has a different resolution, what number this resulting texture is indeed unpredictable which is why I resize it to 256x256 after capture.

The 543x543 texture you see above is a result of the LG-VS840 phone unresized.

 

Then my suggestion would be to either resize the cube or the Rect to the next smaller power-of-two pixelsize before grabbing, since apparently the LG-VS840 has problems grabbing a 543x543 area.
The necessary math is trivial if you use an orthographic Camera, and simple enough if you use a perspective camera.

 

Ok. I'll give that a shot and report my results later tonight. Thank you Wolfram.

Alexey: Bug report # is 514446

 

Alright, I figured out what was going wrong.
ReadPixels has no problems reading non-power-of-two pixelsizes. What was happening was that my cube was apparently going outside of the width/range of the device's screen. The device was a width of 480 and I was looking for 500+ obviously. Doing a simple Max/Min check solve the problem and it's now capturing thumbnails correctly.

So basically if anyone in the future stumbles across this thread, double check and make sure you're staying within the boundaries of the screen space for all devices.