Research
Teaching machines to understand 3D worlds.
A good picture from one angle is only the start. We are interested in technology that understands shape, space and structure, so what it makes can be used, explored and built on.
This page describes research directions: the problems we are working on and why they matter. Where we have learned something from our own production work, we say so. We will publish results as research notes once they can be shown with their methods.
01
3D models
The problem
Generated 3D often looks right in a still image and falls apart in an engine. Messy topology, missing or overlapping UVs, materials that do not respond to light, and meshes that cannot be rigged or deformed all have to be fixed by hand.
Why it matters
An asset is only useful if it fits a production pipeline. Every hour spent repairing a generated model is an hour an artist is not spending on the creative parts of the work.
What we are exploring
- Geometric correctness. Clean topology, sensible UVs and materials that behave under real lighting.
- Rigging and deformation. Characters and objects that bend and animate as intended.
- Consistency. Results that agree from every viewpoint, and props that share one style.
- Editable results. Assets an artist can guide and refine, instead of regenerating from scratch.
What we have learned so far
In our own production, generated or AI-assisted meshes have not been ready to use as they arrive. Topology, UVs and rig weights still need a careful artist's pass before an asset can be animated and lit well.
02
World models
The problem
A world is more than a collection of objects. Terrain, buildings, paths and props relate to one another, and a place has to stay the same place as you move through it, look back, or return later.
Why it matters
Interactive worlds are judged from every angle and at every distance. Without spatial and temporal coherence, generated environments stay a backdrop instead of a place you can play in.
What we are exploring
- Spatial structure. Geometry and meaning together: what things are, where they are, and how they relate.
- Persistence. Environments that keep their structure across viewpoints and over time.
- Change. How light, weather and the things in a world move and behave.
Where we are
This is our earliest area. These are research directions, not a working system, and we have no results to report yet.
03
Creative tools
The problem
Much of making a game is repetitive work: setting up assets, wiring scenes, checking that nothing broke. New tools often ask creative teams to leave the applications they know, or hide what they did so it cannot be inspected or changed.
Why it matters
Tools only help if people trust them. A useful assistant does the heavy lifting inside Blender, Unity and the developer's own workflow, and leaves work the team can read, edit and own.
What we are exploring
- Inside familiar tools. Modelling, engine and development workflows, not a separate walled-off application.
- AI as a collaborator. Automation and coding agents that propose and carry out work a person reviews.
- Validation. Automated checks that catch mistakes before they reach a project.
- Authorship. Every result inspectable and editable, with the decisions left to people.
What we have learned so far
AI coding assistants have been most useful to us when their work is checked automatically. Builds and tests that run on every change catch mistakes early, and make it practical to hand larger tasks to an assistant.
04
Real-time
The problem
Games have to respond in milliseconds on the hardware players own. Graphics memory, latency and the cost of running models all limit what can be used interactively, and what is affordable to experiment with at all.
Why it matters
If useful creative technology needs a data centre, it stays out of reach for independent developers and small studios. Efficiency decides who gets to use it.
What we are exploring
- Rendering performance. Detailed, modern rendering that stays smooth on consumer graphics cards.
- Efficient models. Working within the memory and speed of local hardware.
- Practical deployment. Which parts of a workflow need to be interactive, and which can run ahead of time.
Not every generation step needs to run in real time. Part of the work is deciding which ones do.
What we have learned so far
Performance budgets are set by the hardware players own, not the hardware a game is developed on. Testing early on modest machines changes which ideas are worth pursuing.
Our approach
How we do research
-
01
Grounded in production.
Our questions come from real work on a real game. We judge a result by whether it helps someone finish their work.
-
02
Honest about results.
We describe the methods and inputs behind anything we show, and we publish numbers only with how they were measured.
-
03
Measured by craft.
Benchmarks matter, but so does taste. We also judge results the way artists and players do.
Working on similar problems?
We welcome conversations with researchers, universities, studios and partners.