Can i use GPUI for a game engine?

[ozbeksu]

I would like to build a game engine in rust with gpui and gpui-components.

I would like to know if it is possible to render a 3D viewport or build things like node graph, timeline, inspector. I mean the component parts are easier but 3D viewport?

Renderer
↓
RGBA pixels
↓
GPU texture
↓
GPUI panel

[yhay81]

Yes for the editor shell; not yet as a drop-in, cross-platform 3D viewport host.

GPUI/GPUI Component are a reasonable fit for the inspector, hierarchy, dock panels, menus, property editors, and similar tooling. A node graph and timeline are possible too, but they would be custom interactive components rather than game-engine widgets supplied by this crate.

The 3D viewport is the boundary to be careful about. GPUI's public custom-drawing primitive is canvas(...), which gives a callback into GPUI's own low-level 2D paint API (source). It does not expose an API such as “import this wgpu::Texture and composite it here.”

Your proposed path can be made into a proof of concept:

3D renderer -> CPU RGBA frame -> GPUI RenderImage -> paint_image -> panel

GPUI does have Window::paint_image, but it accepts an Arc<RenderImage> and inserts the image into GPUI's sprite-atlas path (source). That is suitable for images and perhaps a low-rate preview, but doing a GPU readback, CPU copy, and re-upload for a large viewport every frame is exactly the expensive round trip a real-time editor should avoid.

There is one platform-specific exception: GPUI currently has paint_surface for a macOS CVPixelBuffer (source). It is not a portable external-texture interface for Windows/Linux.

For a production viewport, I would choose one of these designs:

1. GPUI shell + initial copied-frame viewport. Render offscreen, read back RGBA, display it as an image, and use this only to validate layout/input/tool architecture. Measure it before investing further.
2. Add an external-texture/custom-scene primitive to GPUI. Share the renderer device/backend, import a texture, and let GPUI composite it without readback. This is the clean same-window result, but currently means upstream work or maintaining a GPUI fork, with separate Metal/Vulkan/DX handling and synchronization.
3. Separate native render surface/window. Let wgpu/Bevy/your renderer own the 3D surface and use GPUI for the surrounding editor. This avoids pixel copies, but docking, clipping, z-order, DPI, focus, and resize integration become platform work.

A practical sequence would be:

• build the editor chrome in GPUI Component;
• define the viewport behind a small abstraction (resize, input, frame presentation);
• first implement the RGBA/RenderImage path at a modest resolution;
• profile copy/upload time and memory bandwidth;
• only then decide between a GPUI external-texture patch and a separate native surface.

Also pin GPUI to an exact Zed commit while doing this. GPUI Component currently consumes GPUI directly from the Zed Git repository rather than a stable crates.io release (workspace dependency), so building an engine integration against a moving main branch will otherwise be painful.

So the short answer is: GPUI Component can be the editor UI, but the zero-copy 3D viewport shown in your diagram is not an existing supported component/API. CPU RGBA frames are a workable prototype, not the architecture I would keep for a 60 FPS editor.

[ozbeksu]

wow, thanks for the detailed answer. i also found this article for those who may be interested in the topic. https://tridentforu.com/blog/posts/gpui-viewport

thanks again. 💯

[Vanuan]

AFAIK, state of the art of everything 3D in gpui is https://github.com/Far-Beyond-Pulsar. They maintain a gpui fork, WGPUI: https://github.com/Far-Beyond-Pulsar/WGPUI

Basic idea is that you patch gpui to add an escape hatch to wgpu, allowing you to have a raw surface within gpui element. Then you could use any 3D engine to draw there.

Another approach is gpui_embedded: https://github.com/zed-industries/embedded_gpui
Originally indended for plugins, you could probably repurpose it to embed gpui within your main 3D app, rather than trying to fit 3D widget within gpui.