koobas.hobune.stream
Texture2D update every frame - The right method
Hi guys,
Apologies if this has been answered before, but I'm struggling to find exactly what I'm after.
I'm playing around with some algorithms that require me to update each pixel of a texture depending on those around it. So I create a Plane, and add a Texture2D via a script to it. I loop through the pixels on each Update(), do the calculations, then the SetPixel(...). At the end, I call Apply(). This all works... But...
... it's terribly slow! Don't get me wrong, I understand that for a 1024x1024 texture, I'm doing a million pixel updates per frame. I'm just wondering if this is the standard way to do this.
Please understand that I'm not asking for ways to optimize the algorithm. I know that one answer might be "only update pixels that have changed". Unfortunately that kind of optimisation is probably more computationally expensive than a simple pixel update.
So my question is:
What's the standard "Canvas" for 2D pixel manipulation per frame?
If I'm doing it right already, I'll shut up. I'm just wondering if somebody's going to say "No, you fool! Use XXXXX" !!
Thanks in advance Richard
Yeah, what are you really trying to do here? This sort of thing is typically done by setting all of the pixels at once (see $$anonymous$$inect camera projects), but individually is quite slow.
Taken from another question: http://answers.unity3d.com/questions/266170/for-different-texture-sizes-which-is-faster-setpix.html
for(int a = 0; a < size*size; a++) {
colors[a]=Color.white;
}
texture.SetPixels(colors);
Create all of your colors ahead of time, then assign them all at once.
To expand on what TreyH is saying, every time you set the pixels ALL of them are reset even if to the same color. So when you call for each pixel individually ins$$anonymous$$d of setting all at once you are setting -a lot- more than millions every frame.
What do you intend to do that needs per frame updating? You can either use render textures, where a camera renders the texture you want live, or you could use a custom shader and tweak its parameters on each frame.
If you absolutely need to update the texture and have more than a few single pixles, use SetPixels instead of iterating SetPixel, this saves you at least some time.
So I'm doing a reaction diffusion algorithm. So each pixel gets evaluated. For sure, some pixels change a little, but unfortunately it is hard to truly garuntee that change wasn't significant.
Not sure on these render textures. I'll take a look.
However, I do like the idea of SetPixel s (). This is easy enough to do as I already have the array setup, so can just dump it out at the end of the update. I know that calling SetPixel() on a 256x256 image took 35ms, so this could make a large difference.
Thanks for this.
I'll add that using SetPixels32 is also faster (less conversions, better CPU cache usage). I'd try using uncompressed RGBA textures too (closer to the color32 struct + no compression involved before being sent to the GPU)
Don't do it every frame and instead limit the check to a couple of times a second, or wrap up inside of a co-routine.
To put it simply though you already answered your own question when you said your doing millions of operations every frame.
So limit how much is done per frame and you will see performance increase
O$$anonymous$$, so what I'm getting here is that I'm going about it in the right way from a rendering perspective.
Thanks for your help and assurance.
If you're familiar with OpenGL/Metal for Android/iOS, you can write the plugin to retrieve the pixel data from render texture and then update the texture which created from you plugin.
This is the best solution we use so far.
