Vienna Game Geometry Library: Collision Detection

The games industry has a gap between "full physics engine" and "nothing," and it mostly fills that gap by defaulting to Unreal, Unity, or Godot. That's not an accident—vendor lock-in is a feature for Epic and Unity, not a bug. The more your physics, rendering, audio, and input are bundled inside one product, the harder it is to leave. Which is part of why a bachelor's thesis from the University of Vienna, presented at the Meeting C++ Student Showcase, is worth paying attention to: Fabian Haßlacher built something that specifically refuses to do everything.

The Vienna Game Geometry Library (VGG) does pure collision detection. Not physics simulation. Not response solving. Haßlacher is explicit about the scope: "pure collision detection—so only the calculations on how objects are colliding and not solving or responding to them. That would be a full physics engine." That's a deliberate constraint, and it's the right one for a library aimed at developers who want to own their own physics response logic without inheriting someone else's entire worldview about how objects should behave.

The Meeting C++ Student Showcase is worth naming as the venue here, not just as attribution. It's a professional C++ conference surfacing the work of undergraduates. That's the actual pipeline for a lot of game tooling infrastructure—academic projects that get picked up, adapted, and absorbed into production codebases, often quietly, often without the original author in the room when it happens. Haßlacher's talk fits that pattern: technically sophisticated, clearly motivated by a real industry need, presented to an audience that can use it.

What VGG Actually Does

The library currently supports four shapes: axis-aligned boxes (no rotation), capsules, polytopes, and spheres. The shape interface is implemented via C++ concepts—a modern compile-time constraint mechanism that defines what any conforming shape type must provide. Per the presentation, a shape must implement four functions: compute_bounding_volume (itself templated on a bounding volume concept), centroid, support, and intersect_ray. The concepts-based design is deliberate—it means the library is extensible without touching core internals.

For polytopes—arbitrary meshes like, say, the Utah Teapot, a standard test model in computer graphics—direct collision detection against raw geometry is expensive enough to be impractical in a game context. Haßlacher's solution is a convex hull builder using the QuickHull algorithm, which wraps the original mesh in a simplified convex approximation. The Teapot demo in his Raylib visualization shows the result clearly: a complex surface reduced to a manageable proxy volume. That's standard practice in game physics, but building a clean QuickHull implementation from scratch as part of a bachelor's project is not trivial work.

The math foundation is Eric Lengyel's Terrathon math library. As Haßlacher described it in the presentation, Terrathon provides wedge and anti-wedge products drawn from a geometric algebra model Lengyel developed—operations for joining and combining geometric objects. Haßlacher flagged the depth of that framework as out of scope for a 14-minute talk and pointed attendees to Lengyel's own work, which is the right call.

The Broad Phase Architecture

The performance story lives in the broad phase, which is where any collision system earns its keep. Brute force—checking every shape against every other shape—scales as O(n²). At 10,000 instances with ~25,000 active collisions, Haßlacher's benchmarks showed brute force taking 190 milliseconds. For context, a 60 FPS frame budget is roughly 16.7ms. Brute force at that scale isn't a collision system; it's a slideshow.

VGG offers two general broad phase algorithms: an index grid (a 3D spatial grid that only tests shapes against their neighbors, parameterized by cell size) and sweep and prune (shapes sorted along an axis using AABB min/max projections to cull non-overlapping pairs). There's also a bounding volume hierarchy option. With optimized broad phase, the same 10,000-instance test came in at approximately 10 milliseconds—Haßlacher noted this himself as representing about 60% of a 60 FPS frame budget. That's a real number worth sitting with: a single collision query consuming 60% of frame time is tight for a production game, but this is a library at version 1.0 targeting eventual GPU acceleration, not a shipping product making claims about AAA titles.

The narrow phase uses GJK and EPA as a general fallback for any collision involving a polytope. For simpler shape pairs—sphere-sphere, capsule-sphere, capsule-capsule—there are dedicated specializations that skip the heavier general-purpose algorithms. Haßlacher's own benchmarks showed the sphere-sphere specialization outperforming GJK significantly, which is what you'd expect when you can replace an iterative convex solver with closed-form geometry. The library routes to the right algorithm automatically based on the shape types involved.

Query results surface the data a physics response system actually needs: collision normals, penetration depth, and two witness points (the closest points on each shape's surface at the collision boundary), plus a separation vector. Ray casting returns hit position, surface normal, and distance along the ray. This is geometry output, not physics output—VGG hands you the contact manifold and leaves the impulse math to you.

"Not by Me"

Near the end of his talk, listing future work, Haßlacher said something that deserves more than a bullet point: "The reason I used concepts originally is because I knew in the future it would probably be extended—not by me, but yeah."

That shrug contains a question the games industry is not great at answering. Who does extend it? Under what terms? The Vienna Game Geometry Library lives in a GitHub ecosystem maintained by Professor Helmut Hlavacs at the University of Vienna—it's part of a broader collection of Vienna projects that includes the Vienna Vulkan Engine. The institutional home exists. But academic projects have a life cycle: student graduates, thesis is filed, repository sits. The concepts-based interface Haßlacher built was specifically designed to make future extension easier for whoever picks it up. That's good engineering practice. It's also a labor transfer, whether or not anyone frames it that way.

The games industry has a well-documented relationship with open-source and academic tooling: consume it, ship it, credit it inconsistently, and rarely fund the person who built it. Bullet, Havok, and PhysX have different origin stories, but the pattern of academic or independent R&D feeding commercial engines without equivalent compensation to contributors runs through all of them. Haßlacher is presenting a bachelor's thesis at a professional showcase. The people in that room are professionals building commercial products. The distance between "this is my thesis project" and "this is inside someone's shipped game" can be very short, and it often travels without the original author's knowledge or participation.

That's not an indictment of Haßlacher's choices or Hlavacs' project—open source is a legitimate way to build and share tools, and the Vienna ecosystem seems deliberately constructed as a shared academic resource. But "not by me" is worth taking literally. Extension, maintenance, and integration all have costs. Someone pays them. In the games industry, it's rarely the person who wrote the original code.

What VGG Is and Isn't

The GPU path is planned but not implemented—the roadmap mentions Vulkan integration as a future acceleration layer, which would change the performance calculus substantially. The current shape set covers the most common game geometry cases, and the AABB-only bounding volume support is a known limitation Haßlacher flagged for expansion. This is a library with a clear architecture and an honest accounting of where it stands.

The separating-concern design—collision detection as a discrete, composable module rather than a subsystem buried inside a larger engine—is an approach the industry could use more of. Whether VGG specifically grows into production use or mainly serves as reference material for the next student who needs to understand how GJK and sweep-and-prune fit together, it's doing useful work. The games industry runs on infrastructure that somebody, somewhere, built as a side project or a thesis or a thing they posted to GitHub and hoped was useful.

Usually that somebody doesn't get a follow-up email.

By Mike Wierzbicki