How do I add a UTexture to an SWindow in C++?

How do I add a UTexture to an SWindow in C++? The SWindow and it’s viewport are being created:

Window = FSlateApplication::Get().AddWindow(SNew(SWindow)
	.Title(LOCTEXT("Camera","Standard Color"))
	.ClientSize(FVector2D(512, 512)));
FSlateApplication::Get().GetRenderer()->CreateViewport(Window.ToSharedRef());

It seems like I should be able to just get the SlateTextureResource and set it to a UTexture but…

I keep running into circumstances where the thing I need is hidden in private layers in the engine. This is really unnecessary and frustrating. If you want to apply a UTexture to a Slate window you could just set the windows TextureResource to a SlateUTextureResource… oh wait… no, you can’t because this is locked away in private… As a C++ library UE4 is sort of abominable, zero (useful c++) documentation, little to no comments on code and half library locked away in private. If you want to make a First Person Shooter using Blueprints, great, look no further, if you want to do anything else and using C++ have fun editing and copying code out of the engine.

If I am just approaching this incorrectly please let me know.

If you hit private that means you doing something wrong way. SWindow widget function is only to create window and only that, not to display graphics in it, you need to put other widget inside a window to display it. Each widget has singular function and they usually don’t do anything beyond there defined ffunction, thats why if you want to have button with text you need to make SButton and then STextBlock inside it, this way Slate is less restrictive on what you can do. Slate in general is very similar on conceptional level and Android UI system which use layout widgets (Compound widgets) containing other widgets and content widgets (leaf widget) and lay them out.

But main problem is that you should not operate with those private varables, i don’t know where oyu get that idea. Widget should have FSlateBrush if it can have any image graphical constant either as constant or background.

FSlateBrush have subclasses, for different graphical images types, for UTextures you use FSlateDynamicImageBrush

For UMaterial (shaders) you use FSlateMaterialBrush

And for external graphical files you use FSlateImageBrush (Yes, it easier to use them in Slate and UMG then in Actors ;p)

You place it in FStaleBrush and it should work.

So in SWindow you place SImage or SBorder (if you want to have widgets on the image) in Cointant argument

and set FSlateBrush in them

If you ever worked with UMG, it is Slate frontend, so if you know UMG you should know how Slate works as it works with same principles it even direly use FSlateBrush and FSlateColor types. You seem to catch on how to create widgets, then only documentation you really need is API Reference:

I there you have whole tree of widget classes listed, each of then have FArgument subclass which contains possible arguments you can use on them, TAttribute type is when you can use binding functions on argument. Example of use you can find in source which seems you already know how to walk in, you dont need to copy paste, if you do just that you not learning at all, you should learn what widget does and what it’s argument does.

The basics are here:

It’s indeed not reach, but main reason why is from fact that Epic expect you to use UMG so thats why it has priority over Slate itself, and Epic most likely expect that if you know Slate, you know how to deal with things yourself, which clearly you have skill to do so, you simply gone little bit too deep in to internal parts of Slate.

Open Slate Reflector in Window->Development Tools, might also open eyes on you how slate works

1 Like

Thanks for the reply. Earlier I tried taking my UTexureRenderTarget2D and used ConstructTexture2D and a FSlateDynamicImageBrush which I add to the SWindow which does indeed work in so far as I can make images paint the SWindow. However, this method uses ReadPixels which is what I was trying to avoid. ReadPixels is a huge slowdown since we are pulling the texture from GPU, blocking the Renderer.

My understanding was that the main viewport for the game was basically an SWindow of some sort, perhaps I am wrong, I really would like to have the SWindow act as a viewport that I can paint with the TextureRenderTarget directly like how I can using AHUD and the main viewport. Really I just want to render my UTextureTargets to a viewport other than the mainviewport. Heck, the viewport does not even need to be visible so long as it exists in memory somewhere so that I can use my post processing on the FSceneViewport rendered scene.