Drawing to Render Target vs Painting Pixels directly in the texture and saving it.

[SophiaWolfie]

I need to paint pixels directly in a texture at runtime. And need this texture to be saved in the content browser / game.
Render targets paint a texture at runtime but dont save it.
So I went C++ for this, and use this code for the most:

UTexture2D* Texture = MyTexture;
FColor* Pixels = (FColor*)Texture->PlatformData->Mips[0].BulkData.Lock(LOCK_READ_WRITE);
Pixels[0] = FColor::Red;
Texture->PlatformData->Mips[0].BulkData.Unlock();
Texture->UpdateResource();

This effectively paints pixel 0 as Red, and even after you stop the game the Texture is still there with the pixel red, which is awesome.
Now I was told not only the LOCK is expensive. There’s a way to save the Render Target at runtime in the game. So that it persists accross sessions.
Is this true?
Can i create a texture using Render Target and then save it in the game content browser for a future session even after i close the game?
Or the C++ system im using is fine?
I though because it was C++, it would be even better/faster, though the truth is, its kind of slow at the moment.

[Suthriel]

@SophiaWolfie

Can i create a texture using Render Target and then save it in the game content browser for a future session even after i close the game?

At least you can export RenderTargets (and Texture2D) to Disk. That should be permanent enough

Video tutorial:

UE4 Importing and Exporting Render Targets (Save and Load) using Blueprints

[SophiaWolfie]

Thanks. So is this cheaper than doing it in C++ with the LOCK thingie?
This is what’s making me undecided. My whole system is for now doing the LOCK. Isnt render targets doing the LOCK thing too?

[RecourseDesign]

Hi, using a rendertarget would only be faster if you did all the pixel writing in a material on the GPU.

Locking a Rendertarget for CPU access would be slower as it copies the pixel data from the GPU to the CPU and back again after.

The BulkData.Lock shouldn’t be slow, it’s just returning a pointer to the pixel data. The UpdateResource may be the culprit there as it’s probably also generating MipMaps.

If the data being written to the bitmap could be done in a material - it would be much faster to go the rendertarget route - you could create materials that do “texture copies” at an X,Y or even straight pixels.

Otherwise you may be able to reduce the time it takes by removing MipMaps from the Texture2D (MyTexture->MipGenSettings=TMGS_NoMipmaps), but then if you’re using that texture in game, it will store the full sized texture in VRAM at all times.