Render only parts of the screen, fill rest with UI

How would I do something like this in UE4?

gameboy-emulator-iphone.jpg P1040284-640x480.jpg

Only a specific part of the game should render the 3D world, while the other space on the screen should be filled with UI elements (UMG). I want to do this to save performance, since the UI is always hiding certain areas in the game, most importantly a certain percentage at the bottom of the screen.

If I just put UMG widgets on the screen,the world below is still fully rendered, the UMG widgets just hide it after its rendered. I know I could render the game to a RenderTarget and then draw it on my UMG UI, but using a SceneCapture2D as the main camera for the game does not sound like a great idea to me. There is surey a way better way to do this.

Any ideas?

I would also be interested in knowing how to do this. I’d consider the SceneCapture method, but since my game relies heavily on mouse interaction within the 3D world, RenderTargets seem like the wrong way to go.

Bump.

Has anyone found a solution for this? I’ve been looking around for quite a while now and haven’t seen anything…

The current solutions aren’t really any good. But there is hope, I asked separately and as a result there is a pending feature request. Vote for it and hopefully it becomes a reality.

For a while now (tried since 4.7, but works all the way to 4.13) even with ‘Use Splitscreen’ disabled (in Project Settings, Maps & Modes, Local Multiplayer section) you can still adjust percentage of the screen to be used for rendering.

SplitScreen info can be accessed and adjusted directly. These values may give you what you need:



GEngine->GameViewport->SplitscreenInfo[0].PlayerData[0].OriginX = .05f; // default: 0.f
GEngine->GameViewport->SplitscreenInfo[0].PlayerData[0].OriginY = .02f; // default: 0.f
GEngine->GameViewport->SplitscreenInfo[0].PlayerData[0].SizeX = .4f; // default 1.f
GEngine->GameViewport->SplitscreenInfo[0].PlayerData[0].SizeY = .2f; // default 1.f


Make sure to check for validity of pointers used, and array indices, and, preferably run this in BeginPlay of the pawn or controller owning the widgets (presumably will not exist otherwise)

Areas outside of these will be rendered in black, so you’ll need to make up a widget to cover it with different color. :slight_smile: Camera positioned in the ‘middle’ of viewport will accurately be in the middle of the area you are rendering.

Edit: Widgets positioning will not be affected, so if you use widgets to draw stuff on top of render area, you’ll need to manually adjust these.

It seems like I’m getting the full cost of rendering the original camera viewport, even with split screen cutting off a major portion of the final image. Even with the entire original camera cropped (so there’s only a black screen visible), I’m actually getting worse fps. The split screen feature might just be rendering the original view to a render target and then just scaling and cropping, which would actually increase the render cost. So I would NOT recommend using the split screen feature for doing this. You’re better off just blocking the portion you don’t want visible with a black rectangle. It’s pretty frustrating that UE4 lacks so many basic features.

Wow if that is true, then it is really bummer as I just spend a few days researching alternative to using 2 rtt texture (SceneCapture2D)… Is that true Epic?

how about a camera-faced plane instead of umg,just guess

I’m having the same issue. Is the best solution still to go in to cpp and access player data and set the size like @xulture described above? also @anonymous_user_b31da257 's link doesn’t work, is this still a feature request?

I’d like to know if this is updated on 2018?

ndisplay may can do this

its work!

I would just like to clarify this is not true anymore. It was probably different back then in 2016, but now it is not the case. Cropping the viewport using the quoted method actually gives you FPS gains because you’re rendering less on screen! Just commenting this as this thread comes up on google

FWIW: Reading the thread, I’m not convinced the original problem was that there were no rendering gains.
It’s just as likely that the lack of FPS gains were because the GPU simply wasn’t fill rate limited, so something else was the bottleneck.
Transform, data transfer, CPU, physics, or a bunch of other things may be limiting you, and making the screen bigger/smaller won’t change anything if that’s the case.