SetPixels() called with invalid # of pixels in the array - Scaling? about asynccapturetest HOT 16 CLOSED

I am able to reproduce this in the clean-slate project if I use a render texture instead of having the camera render to 'Display 1' as it does in the provided scene.

Am thinking it's a bug -- this is closest I could find, though it's marked fixed in 2018.3:
https://issuetracker.unity3d.com/issues/asyncgpureadback-setpixels32-called-with-invalid-number-of-pixels-error-when-changing-aspect-ratio

from asynccapturetest.

Thanks for reporting the issue. Unfortunately, I can't reproduce the issue on my MacBook (macOS 10.14.4, MacBook Pro Retina 15" Late 2013 with GeForce GT 750M) with Unity 2018.3.12f1.

Please try updating Unity to the latest. If it still reproduces, try changing GPU to use from Preferences -> General -> Device To Use.

from asynccapturetest.

I was hoping 2018.3.12f1 would fix it too -- unfortunately I'm getting the same result after updating to 2018.3.12f1 today though.

I'm on a Mac Pro with 'FirePro D500' GPUs. I'm currently set on 'Auto' in that menu but the only other option is the D500.

I thought I was seeing the same thing on MBP Retina 2015 but I'm not 100% -- was late night tinkering few nights ago, so I'll try to repro it on the MBP and report back.

from asynccapturetest.

It appears as though checking the 'Allow HDR' setting on the Camera is what causes this.

Minimal repro
Clone this project, run it, and then check the 'Allow HDR' on the camera.

That's with 2018.3.12f1 running on macOS (10.14.3) on a 15" Macbook Pro Retina (Mid 2015). Two cards on this machine but it repros on both -- I've got it set to 'auto' but tested when set to both and same thing occurs as well (AMD Radeon R9 M370X & Intel Iris Pro).

from asynccapturetest.

And I now realize that the other issue is related to this same thing, so I've probably just dupe-reported it in a round-about way heh. =D

from asynccapturetest.

If you're using HDR, you can't use GetData<Color32>() because the pixel format of the render texture is not Color32. You have to determine the actual pixel format (there are some options like ARGBFloat, ARGBHalf, RGB111110Float, etc.) and use a proper data format to retrieve them, it's pretty troublesome though.

Instead of directly accessing the HDR texture, I'd recommend converting it to ARGB32 before readback. Allocate a ARGB32 render texture in Start(), blit source to it in OnRenderImage, them read it back.

from asynccapturetest.

Got it, thank you very much! Mostly makes sense to me, though am admittedly a complete beginner when it comes to graphics programming, and was surprised to see just how many formats there were in that enum hah.

I was indeed able to get it working though, so thank you a TON -- it's actually quite intriguing, can see decent bit of potential use-cases where might be able to offload some misc. CPU tasks (extrusions in particular, maybe some FOV stuff, etc) to GPU in pixel-format maybe. Pretty cool. :)

I'm curious if there's any way to profile it overall, to better understand what my 'capacity' is? I don't have GPU profiling compatibility on this machine, am guessing that may show insight though?

Also would be curious if you have any thoughts on best way to get this to disk without tying up the main thread (current use case is the common one -- screenshots/timelapse); I thought I was home free until I realized Texture => bytes[] was "main thread only" call. Does at least allow me to offload the IO, and I'm sure I can dig up Color[] => bytes[] in a lib somewhere, but would be curious if there's a more direct approach that exists perhaps?

Thank you very much -- so hugely helpful, and I apologize for the newbie-esque questions / sorry for having wasted your time, though the guidance is very much appreciated.

from asynccapturetest.

Sorry but I can't afford time to consult each case in details. I can't speak English so reading and explaining this kind of issues consumes lots of time.

My understanding is that the original issue was solved, so I'm closing this issue ticket now. Please reopen the ticket when the issue reproduces again. Thanks.

from asynccapturetest.

Yep, all resolved, no worries. Thank you!

from asynccapturetest.

Hey,
I was trying to run the Test Scene in this project on my system but the error "SetPixels32 called with invalid number of pixels in the array" came up.

I didn't make any changes to the project.
I tried running it on Unity 2018.3.0f2 and 2018.4.4f1 on Windows 10(with GTX 970M and i7 2.60 GHz 4th Gen)!

from asynccapturetest.

@geekyJock8 Does it reproduce when explicitly setting the game view resolution from the drop down?

from asynccapturetest.

No, it doesn't!
When I choose an absolute resolution(like 1024x768), there's no error!
But When I choose Free Aspect or a ratio(like 5:4), the error occurs!

Can you explain why this is happening?

from asynccapturetest.

@geekyJock8 I have no idea because it doesn't reproduce on my side. My understanding is that some specific graphics APIs or drivers only support multiples of 8 in a texture pitch (width). I recommend keeping the screen width in a multiple of 8, or if you have to use an odd number in the screen width, blit the frame to a temporary render texture to rescale it to a multiple of 8.

from asynccapturetest.

After you suggested changing the resolution, I played around with several configurations and here are the results:

1. Relative Ratios(e.g. 5:4, 4:3), Low Aspect Resolution = True: No Error
2. Relative Ratios(e.g. 5:4, 4:3), Low Aspect Resolution = False: Error
3. Fixed Resolution(e.g. 1920x1080, 577x757) : No Error
4. Free Aspect, Low Aspect Resolution = False: Error
5. Free Aspect, Low Aspect Resolution = True: No Error

I don't the error is due to the width not being multiple of 8. Thanks for the help!

from asynccapturetest.

Got it, thank you very much! Mostly makes sense to me, though am admittedly a complete beginner when it comes to graphics programming, and was surprised to see just how many formats there were in that enum hah.

I was indeed able to get it working though, so thank you a TON -- it's actually quite intriguing, can see decent bit of potential use-cases where might be able to offload some misc. CPU tasks (extrusions in particular, maybe some FOV stuff, etc) to GPU in pixel-format maybe. Pretty cool. :)

I'm curious if there's any way to profile it overall, to better understand what my 'capacity' is? I don't have GPU profiling compatibility on this machine, am guessing that may show insight though?

Also would be curious if you have any thoughts on best way to get this to disk without tying up the main thread (current use case is the common one -- screenshots/timelapse); I thought I was home free until I realized Texture => bytes[] was "main thread only" call. Does at least allow me to offload the IO, and I'm sure I can dig up Color[] => bytes[] in a lib somewhere, but would be curious if there's a more direct approach that exists perhaps?

Thank you very much -- so hugely helpful, and I apologize for the newbie-esque questions / sorry for having wasted your time, though the guidance is very much appreciated.

Hello! wondering how you got this working, I've been having issues properly getting this working, my the written file always just seems to be completely black

from asynccapturetest.

I think this issue doesn't reproduce anymore. Please submit a new issue if it still reproduces.

from asynccapturetest.