UpdateTextureRegions Pitch

[jgm]

Hey,

I’ve been trying to update a dynamic texture from C++ using the UTexture2D::UpdateTextureRegions function. I’ve created the texture by

if (!Texture) {
	Texture = UTexture2D::CreateTransient(512, 512, PF_B8G8R8A8);
	Texture->UpdateResource();
}

and try to update it using the UpdateTextureRegions function

The signature of UpdateTextureRegions is

UpdateTextureRegions(int32 MipIndex, uint32 NumRegions, const FUpdateTextureRegion2D* Regions, uint32 SrcPitch, uint32 SrcBpp, uint8* SrcData, TFunction<void(uint8* SrcData, const FUpdateTextureRegion2D* Regions)> DataCleanupFunc)

And I use it like this:

if (!Texture && Texture->Resource)
	return;

uint8* Data = new uint8[512 * 512 * 4];
for (uint32 i = 0; i < 512 * 512; i++) {
	uint32 u = i % 512;
	uint32 v = i / 512;
	Data[i * 4 + 0] = uint8(0);
	Data[i * 4 + 1] = uint8(v);
	Data[i * 4 + 2] = uint8(u);
	Data[i * 4 + 3] = uint8(255);
}

FUpdateTextureRegion2D* Region = new FUpdateTextureRegion2D;
Region->DestX = 0;
Region->DestY = 0;
Region->SrcX = 0;
Region->SrcY = 0;
Region->Width = 512;
Region->Height = 512;

TFunction<void(uint8* SrcData, const FUpdateTextureRegion2D* Regions)> DataCleanupFunc =
	[](uint8* SrcData, const FUpdateTextureRegion2D* Regions) {
	delete[] SrcData;
	delete[] Regions;
};

Texture->UpdateTextureRegions(0, 1, Region, 512, 4, Data, DataCleanupFunc);

But I haven’t gotten the texture to align properly and I think the issue is the pitch parameter. The result looks like this:

Does anyone have a good explanation of what the pitch is, and what value it should be? Or maybe if the issue is caused by something else?

Non of the results I get when i search tell me what the pitch really is, and in the DX11 documentation it seems to be the total width of the data.

[jgm]

The result actually seem like they are correct if i let the pitch be 512 * 4 (e.g. the width of the texture data in bytes). Is that what it is supposed to be?

[anonymous_user_c3e69a5a]

Yes, the pitch needs to be in bytes. So its width * bytes_per_pixel,
in your case 512 * 4!

And this seems to be a bit redundand, since the next parameter is the count of bytes per pixel, if you take a look at [the documentary][1]. But thats just how it is