Home | Documentation | Atomic Chat | Github

Static full-viewport 2D background texture with 3D models and UI rendered in front


Hello. Just starting on my first atomic engine project. I’m wondering what the recommended process for rendering a game with a static 2D full-viewport background image and 3D models and UI in front of it. Think early 3D final fantasies, but easier since there won’t be depth information in the static 2D background (the 3D models will always render in front of it) and there’s no need for scrolling.

The hackish way is to use a 2D sprite and just have it always behind the 3D characters. But I’m wondering if there’s some functionality to draw screenspace images in the background so I don’t have to worry about depth or perspective projection screwing up how it’s rendered.



Hi Christopher, welcome to our humble community!

While you certainly could draw the background separately from the rest of the objects, and then draw the rest of the scenes on top of it, I don’t think it’s worth the effort, especially because if you ever want to add some complex effect in which the objects affect how the background is rendered, you’d need to submit the data to the GPU anyway. If you’re worried about ztesting you could simply draw the background without writing to the z channel, or clear it after drawing the background since you’ll have to clear it at some point and if you’re drawing over the entire framebuffer you don’t have to clear other stuff anyway. These days blitting pixels isn’t used any longer and most games use hardware acceleration for drawing which means you’re submitting basic geometric data to instruct the GPU on what/how to draw.

If you just want to draw a background image independently anyway, I don’t think there’s a simple draw command for that (but I could be wrong), so I guess you’d have to prepend a render path event and pass the geometric data to render, what should be very easy to wrap into a function in any case.

Hope this helps.


Turns out making a background without working in screen space wasn’t as problematic as I thought it would be. Plus I get the benefits mentioned in your post.

Thanks for the help!


Glad I could help.
Converting between screen and world space surely isn’t a problem, and there are in fact some auxiliary functions like WorldToScreen/ScreenToWorld in the Camera object that under the hood just use the camera projection matrix anyway. It definitely won’t be hard to just position a sprite at the limit of the camera clipping, although you certainly will have to put some thought on the behavior regarding different aspect ratios. Keep in mind to also leave some room for fp accuracy issues, if you position a sprite exactly at the limit of the camera far clip, in some hardware the sprite may be culled due fp differences.