# g3n/engine: an OpenGL 3D engine written in Go, and what it costs to use one

> g3n/engine is a cross-platform OpenGL 3D engine in Go with an integrated GUI, OpenAL spatial audio and glTF/OBJ/COLLADA loaders. Its install path is a C toolchain away from a plain Go build, and its last tagged release was v0.2.0 in 2021.

**g3n/engine** — Go 3D Game Engine (http://g3n.rocks)

- Repository: https://github.com/g3n/engine
- Website: https://discord.gg/NfaeVr8zDg
- Stars: 3,117 · Forks: 312
- Language: Go
- License: BSD-2-Clause
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/g3n-engine

## What g3n/engine is for, and who it is actually aimed at

The README describes g3n/engine (pronounced "gen") as an OpenGL 3D Game Engine written in Go, usable for cross-platform Go applications that show dynamic 3D representations, "not just games". That phrasing is the honest description of the audience. The people who get value here are Go developers who already have a program, a tool or a simulation and want a 3D view inside the same binary, without shipping a browser or a separate rendering process. The repository is organised as a set of packages rather than one monolith: app, window, gls, core, graphic, geometry, material, light, camera, renderer, gui, audio, loader, texture, animation, math32 and text sit side by side at the top level, with an experimental package and a tools directory. That layout tells you the engine is meant to be consumed as a library you assemble, not driven through a scene editor. There is no editor in the repository. A user writes Go code, builds a node tree, and the engine draws it. The project points to g3nd as its demo application and to Gokoban, which took first place in the 2017 Gopher Game Jam, as a game built on it. Those are the two reference points for what the engine can carry.

## How the scene graph, renderer and GUI manager fit together

The mechanism is visible in the hello world listing. app.App creates the window and the OpenGL context. core.NewNode creates a scene node, and gui.Manager().Set(scene) hands that node to the GUI manager, which means the GUI is not a separate overlay system: it lives in the same scene graph as your meshes. A camera is created with camera.New(1), positioned, and added to the scene like any other node, and camera.NewOrbitControl(cam) attaches orbit behaviour to it. Geometry and material are separate objects: geometry.NewTorus builds the vertex data, material.NewStandard builds the shading parameters, and graphic.NewMesh pairs them into a drawable node. The renderer package is what walks the graph each frame. Window events arrive through a subscription model: a.Subscribe(window.OnWindowSize, onResize) registers a callback, and the same pattern is used for GUI input, with btn.Subscribe(gui.OnClick, ...) handling a click. Because the scene graph is hierarchical, nodes can contain other nodes, which is how transforms compose. Lights are nodes too, added to the same graph, with ambient, directional, point and spot variants listed in the features. The material system implements physically-based rendering, described in the README as fresnel reflectance, geometric occlusion and microfacet distribution. Custom GLSL vertex, fragment and geometry shaders are supported, so a project that outgrows the standard material can supply its own. The renderer package is also where a server-side rendering path could attach, which is what the linked webg3n project does.

## Installing g3n/engine on Linux, macOS and Windows

This is not a pure Go dependency. The README states that Go 1.8+ is required, along with an OpenGL driver and a GCC-compatible C compiler, because the engine binds to GLFW, OpenAL and Vorbis through cgo. On Ubuntu or Debian-like systems the README gives this package list:

```bash
sudo apt-get install xorg-dev libgl1-mesa-dev libopenal1 libopenal-dev libvorbis0a libvorbis-dev libvorbisfile3
```

Fedora takes a different set, including mesa-libGL-devel, openal-soft-devel, libvorbis-devel and glfw-devel. CentOS 7 requires enabling EPEL first, then the Fedora packages with yum. Arch uses base-devel, xorg-server, mesa, openal and libvorbis. Void has its own xbps-install line. On macOS the README says to install the development files with Homebrew:

```bash
brew install libvorbis openal-soft
```

On Windows the README states the build was tested with the mingw-w64 toolchain, and that the necessary audio DLLs are supplied in the audio/windows/bin directory and need to be added to PATH. Once the system libraries are in place, the engine itself installs like any Go module:

```bash
git clone https://github.com/g3n/engine g3n-engine
cd g3n-engine
go install ./...
```

The go.mod file pins go-gl/glfw v3.3, golang/freetype, golang.org/x/image and gopkg.in/yaml.v2, so the Go toolchain will fetch those on first build. If the C headers are missing, the failure appears at compile time in the cgo step, not at runtime, which is the easier place to debug it.

## A first real scene: a torus, a light and a button

The README's hellog3n example is the shortest useful starting point, and it exercises the parts that matter: window creation, scene graph, camera control, a mesh, lighting and GUI input. The core of it looks like this:

```Go
a := app.App(800, 600, "Hello World")
scene := core.NewNode()
gui.Manager().Set(scene)
cam := camera.New(1)
cam.SetPosition(0, 0, 3)
scene.Add(cam)
camera.NewOrbitControl(cam)
geom := geometry.NewTorus(1, .4, 12, 32, math32.Pi*2)
mat := material.NewStandard(math32.NewColor("DarkBlue"))
mesh := graphic.NewMesh(geom, mat)
scene.Add(mesh)
```

What you should see after building and running it is an 800 by 600 window containing a blue torus that you can orbit with the mouse. The example then adds a button and a click handler that calls mat.SetColor(math32.NewColor("DarkRed")), so clicking the button turns the torus red. That single interaction is the useful part of the tutorial: it shows that GUI widgets and 3D meshes share the scene graph and that material state is mutable at runtime. The example also registers a window resize callback that calls a.Gls().Viewport(0, 0, int32(width), int32(height)) and updates the camera aspect with cam.SetAspect(float32(width) / float32(height)). Without that callback the projection stretches when the window is resized, which is a common first bug. Lighting is added as nodes: an ambient light with intensity 0.8, then a point light, both added to the scene. Remove the lights and the torus renders black, since the standard material is lit.

## Where g3n/engine is the wrong tool

The physics engine is the clearest boundary. The README lists it as "Integrated basic physics engine (experimental/incomplete)". That is the project's own wording, and it should be read literally: if your application depends on collision response, constraints or stable simulation, this package is not the foundation for it, and there is no separate physics module in the top-level layout to fall back on. WebAssembly is the second boundary. The feature list says "WebAssembly is 90% complete", which means a browser target is not something to plan a release around. The third boundary is the release cadence. The newest tagged release is v0.2.0 from 2021-08-19, and before that v0.1.0 from 2019-09-07. The repository has been pushed to since then, with the most recent push on 2026-08-01, but a consumer who tracks tags rather than commits is working from a five-year-old release. The fourth is the dependency surface. Because the engine needs an OpenGL driver and a C compiler, it does not fit headless build machines or CI runners without a GPU stack, and the Windows path additionally needs the supplied audio DLLs on PATH. If your deployment target is a container without graphics libraries, or a server where you only need to compute geometry, the engine's rendering half is dead weight. Finally, the GUI is described as basic and integrated; a project that needs a full widget toolkit with accessibility support will find it thin.

## g3n/engine against a general-purpose Go 3D library

The honest comparison is with a lower-level Go binding such as go-gl, which exposes OpenGL directly without a scene graph, and with an engine that ships an editor and a full toolchain. The difference is where the abstraction sits. go-gl gives you GL calls and leaves node hierarchies, materials, cameras, model loading and input dispatch to you; adopting it means writing the parts g3n/engine already provides, including the glTF, OBJ and COLLADA loaders, the geometry generators (box, sphere, cylinder, torus), the TrueType text support, the sprite sheet animation, and the GUI manager. An editor-centric engine gives you the opposite trade: a visual workflow and a data format, but your application logic lives inside that engine's runtime rather than inside a Go program you control. g3n/engine sits in the middle, and the middle is where its appeal and its limits both come from. You get a scene graph and a renderer as Go packages, and you keep the Go build, the Go tooling and the ability to embed the engine in a non-game program. What you give up is the ecosystem that surrounds a larger engine: no editor, an experimental physics module, and a WebAssembly target that the README calls 90% complete. A team already writing Go, whose rendering needs are meshes, lights, materials and a small control panel, gets more from g3n/engine than from raw GL bindings. A team whose needs start with physics or a browser build should look at an engine that treats those as first-class.

## Maintenance, upgrade cost and the BSD-2-Clause licence

The repository is not archived, and the last push was on 2026-08-01. That is recent activity, but the release history is the number that matters for upgrade planning: v0.2.0 landed on 2021-08-19 and v0.1.0 on 2019-09-07. A project that depends on g3n/engine should therefore decide early whether it pins to the v0.2.0 tag or tracks master, because those are different maintenance postures. Pinning to the tag means the Go module dependencies in go.mod stay where they are, including the go-gl/glfw v3.3 pseudo-version and golang.org/x/image from 2021, and you inherit whatever those versions do on current toolchains. Tracking master means the module line moves with the repository, and you take on the cost of rebuilding against cgo dependencies that can break when a system library changes. Note that go.mod declares go 1.13, while the README asks for Go 1.8+, so the module file is the stricter of the two statements. The licence is BSD-2-Clause, which is permissive: it allows use in closed-source products provided the copyright notice and licence text are retained. That is a summary of the licence identifier in the repository, not legal advice, and anyone embedding the engine in a shipped product should read the LICENSE file at the repository root. The audio path has its own consideration: the Windows build ships prebuilt DLLs in audio/windows/bin, and the README points to audio/windows for their source and build instructions, so a distributor needs to account for those binaries separately from the Go code.

## Conclusion

Adopt g3n/engine if you want a 3D scene, GUI widgets and spatial audio inside a single Go binary and you accept cgo plus system OpenGL and OpenAL libraries as part of your build. Do not adopt it if you need a mature physics simulation, a WebAssembly target today, or a project with recent tagged releases; the newest release is v0.2.0 from 2021-08-19. Before committing, verify that your target machines have an OpenGL driver and the audio DLLs or shared libraries on the loader path, then run the hellog3n example unmodified on each one, because that is where the cgo and audio linking problems surface first.

## FAQ

### Is g3n/engine free to use?

The repository is licensed under BSD-2-Clause, a permissive licence that allows commercial and closed-source use as long as the copyright notice and licence text are kept. Read the LICENSE file at the repository root for the actual terms.

### How do I install g3n/engine?

Install the system C libraries first (for example xorg-dev, libgl1-mesa-dev, libopenal1, libopenal-dev and the Vorbis packages on Ubuntu or Debian-like systems), then clone the repository and run go install ./... inside it. A GCC-compatible C compiler and an OpenGL driver are required.

### Does g3n/engine work on Windows and macOS?

The README lists Windows, Linux and macOS as supported platforms. On macOS it says to install libvorbis and openal-soft with Homebrew; on Windows it says the build was tested with mingw-w64 and that the audio DLLs in audio/windows/bin must be added to PATH.

### Can g3n/engine run in the browser through WebAssembly?

The feature list states that WebAssembly is 90% complete, so it is not presented as a finished target. Treat browser output as unfinished and plan around a native build.

### Which 3D model formats can g3n/engine load?

The README lists model loaders for glTF (.gltf and .glb), Wavefront OBJ (.obj) and COLLADA (.dae). Textures can be loaded from GIF, PNG or JPEG files, and audio through OpenAL supports .wav and .ogg.

### Is the physics engine in g3n/engine ready for production?

The README describes it as an integrated basic physics engine that is experimental and incomplete. It is not a safe dependency for projects that need reliable collision response or constraints.

## Sources

- [g3n/engine on GitHub](https://github.com/g3n/engine)
- [License: BSD-2-Clause](https://github.com/g3n/engine/blob/master/LICENSE)
- [Project website](https://discord.gg/NfaeVr8zDg)
- [README](https://github.com/g3n/engine/blob/master/README.md)
- [Releases](https://github.com/g3n/engine/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/g3n-engine