The Teapot Test: From Showing to Making

In 1975, in Salt Lake City, Martin Newell needed an object to test a renderer, but nothing in the lab worked. He went home, sat at his kitchen table with a ruler and graph paper, measured his family's teapot, and entered every coordinate by hand. The teapot was his wife's suggestion, which may have been the first great piece of art direction in the history of computer graphics.

That simple teapot ended up shaping how we think about 3D. For 50 years, this community has carried forward the same experimental spirit, turning practical hacks into breakthroughs. Consider what Newell was actually doing: a human being was measuring the world point by point, and every coordinate passed through the filter of a person's fingers.

Here is the strange part. Everything this community has built since then—path tracing, physically based rendering, simulation, and more—exists downstream of that act. Yet the act itself has never changed: a human translates the world into coordinates. We have simply become very good at everything around it.

Now, this is where we are: no ruler, no graph paper, just one sentence—and a beautiful video comes out. The camera moves where you ask it to, and the polished porcelain surface catches the light perfectly. Some call these systems world models.

Is this it? Is this the endgame? These models are certainly magnificent, but let us try something. We are going to ask this small teapot for three small favors. It is only a teapot — how hard can it be to: Put it in a game? Print it? Or use it to teach a robot to pour tea?

Every request receives the same answer: nothing. There is no teapot. There may be gorgeous pictures of one, viewed from any angle, but there is nothing behind those pictures. You can look around it, but you cannot touch it.

Fifty years ago, the teapot tested whether machines could show. Today, these three requests test whether machines can make. We call this the Teapot Test. Machines learned to show things. Now we are teaching machines to make things.

The Evolution of 3D Generation

For roughly 50 years, computer graphics focused on showing the things we made: better lighting, better materials, and better simulation. Images became increasingly realistic. For many years, the main goal was to improve the final image, and this work gave us the tools on which modern 3D generation is now built.

But is a good image always a good 3D asset? Not necessarily. The shape may be broken. Its parts may not move. It may not work in a real production pipeline for a player, a maker, or a robot. These details matter.

Early models learned to create attractive images from text or other images. That was a major step, but a good image could still contain bad geometry. We therefore began moving from making things look right to making things work.

The first era emerged around 2022 and 2023. DreamFusion and Zero-1-to-3 used complex optimization processes. They repeatedly adjusted a 3D representation until the rendered views matched an input image or text prompt. This gave us a 3D object that we could rotate and inspect. However, the process was slow and expensive. It required many rounds of rendering and optimization.

In the second era, models learned a faster path from an image to a 3D shape. InstantMesh, for example, can produce a mesh from a single image in less than half a second. This was a major shift: we could generate, check, and try again very quickly. But was speed enough? Not yet. The shape could still be difficult to edit, print, or animate.

This is where the focus began to shift from speed to control. The third era, from around 2024 to today, is native 3D generation. The model learns more than what an object looks like; it learns what the object needs to do. A useful asset has connected surfaces. Its parts can move, its materials can change, and it can support the next step in a real workflow.

Projects such as TEXGen, TripoSG, SparseFlex, ShapeGen, and Nexus are moving in this direction. The transition from 1.0 to 3.0 is not only about better images; it is about better assets. An asset should be ready for the next person, the next tool, or the next machine. This is a deeper change: the model must understand more of the object's structure.

The model is only one part of the complete system. We no longer evaluate the model alone; we evaluate the entire workflow. The question is no longer simply, "Can it generate?" The question is, "Can the result be used?"

This work requires a team that builds the models, tools, and tests together. The numbers show the scale: three years, more than 60 papers, 20 million creators, and approximately 200 million objects made. Every object generated gives us feedback. We learn what works and what fails. A method may look good in a paper but fail in practice. Real users expose these gaps very quickly.

Our default is to be open. These projects span many parts of the 3D pipeline, including generation, shape creation, rigging, animation, and view control. Why does openness matter? 3D generation is a chain of steps. When those steps are open, people can reproduce results and identify problems faster. A paper becomes a tool, and a tool becomes a new experiment. This is how progress builds on itself.

The loop is simple: research, models, tools, use, and verdicts. We make a tool and watch people use it. We ask: does it solve the real task? Where does it fail? This loop keeps research close to real needs. For us, a repeatable result is more valuable than one perfect demonstration.

3D generation is similar to code generation. With code, generating the code is not enough: it must run, be tested, and ship. The same is true for 3D. An attractive asset is not enough. The output we trust is the output that runs, is tested, and ships.

This brings us to the Teapot Test. For players: can we put it in a game? For makers: can we print it? For machines: can we use it to teach a robot? These are simple questions, but they take us beyond the screen.

For players.

Can we put it in a game?

We start with something familiar: games. In one sense, perhaps everyone is a game player. You may not be a fan of AAA games, but you have probably seen 2D games. Two-dimensional games simply demand less. Three-dimensional games are much more complex.

A 3D scene brings together a large number of 3D assets, and producing those assets is one of the most time-consuming parts of game development. Game assets must meet certain standards, all in service of high quality and high performance. An asset needs a reasonable polygon count so that it can be rendered and stored efficiently. It also needs good topology to support realistic animation.

This is the traditional pipeline for creating a 3D asset, and it can take a great deal of time. We typically begin with geometric modeling, followed by manual sculpting to add surface details. Next, we manually retopologize the detailed asset into a lower-polygon mesh. After that comes UV unwrapping, texturing, rigging, skinning, and other steps. A simple asset can take hours, while a highly complex asset can take days.

At Tripo, our goal is to reduce this time from days to hours, and from hours to seconds. This year at SIGGRAPH, we achieved an important breakthrough with a paper called Nexus. From a single input image, Nexus can produce high-quality meshes with strong topology in only a few seconds.

It follows a two-stage pipeline. First, we generate mesh vertices using a hierarchical octree structure. Then we determine how those vertices should connect to form faces. Users can also request different levels of detail by specifying the desired polygon count. With Nexus and its future improvements, we believe a large portion of the modeling process can be replaced at very low cost.

Beyond static assets, we have also explored how to make assets animatable. UniRig is our SIGGRAPH 2025 research project, in which we use autoregressive generative models to perform rigging and skinning for any given mesh. We can now rig and skin not only humanoids, but also many kinds of non-humanoid characters, including birds, fish, and winged monsters.

This research has been successfully deployed in our AI 3D platform, Tripo Studio, and is also available for developers through our OpenAPI platform (https://developers.tripo3d.ai). At the SIGGRAPH Real-Time Live! session, we demonstrated how these research projects can be combined to create game assets extremely quickly. In under six minutes, we showed how AI 3D techniques could help a creator build an attractive car-racing game. It was a great honor to receive the Best in Show award.

We have built deep collaborations with leading game studios, helping them introduce AI-assisted workflows for producing real, high-quality games. But beyond game development, another interesting and growing direction is the use of AI-generated assets inside the game itself. Assets are generated on the fly at runtime, which requires a higher level of automation.

One example from our community is LeBot. It uses the Tripo API to generate the main character from a photo uploaded by the player, so you can put yourself into the game. It also performs rigging and skinning, allowing the character to execute a full range of combat actions. Another case is Florii, a flower-arrangement game where everything—flowers, vases, and baskets—is AI-generated. Generative AI is essential to the gameplay, but players still experience the pleasure of arranging the flowers themselves.

For players, then, it is safe to say that AI-generated assets can already be put into games.

One question may still concern many: will this replace artists? Two years ago, at CVPR 2024, Anastasis Germanidis, the CTO of Runway, said something inspiring: "Science is about modeling the distribution, but art is about going out of distribution."

The goal is not simply to automate everything; human intention remains central. The eye for silhouette, the sense of what makes a character feel alive, and the judgment of what is beautiful still come from a person. LeBot and Florii send a strong signal: people love to create, and they want to live in worlds they have created. This is becoming a new genre of gameplay. In that genre, everyone can become an artist. Artists will not be replaced. There will be more artists.

For makers.

Can we print it?

We have already asked whether and how generated objects can enter a game engine. But a good game asset does not necessarily make a good 3D-printing asset.

For a game asset, the goal is to look good on a screen. We care about polygon count and clean topology, and we can use normal maps or texture maps to add details that are not actually present in the geometry. A 3D-printed asset is different. There is no texture map or normal map to hide behind. The geometry itself is the result.

Let us take this object out of the screen and into the real world. On a screen, details only need to look real. In your hand, they must be real. Every groove and tiny feature must exist as actual geometry, with real thickness that a printer can produce.

Before we print, we need to answer one simple question: is the detail really there? Imagine that we want to print a character as a figurine. From a distance, it looks good. But when we zoom in, it does not hold up. The face becomes softer, and many of the finer details begin to disappear. That is precisely what the zoom-in test is designed to reveal.

When we examine a truly print-ready result, the face retains its shape. The grooves and raised patterns do not dissolve into a blur. These details are genuine 3D forms rather than paint applied to the surface.

In standard workflows, conventional approaches usually convert the raw mesh into a watertight signed distance field and then extract the final surface using marching cubes. However, this conversion often comes at the cost of geometric quality. Sharp edges become smoothed, and thin features tend to become too thick.

To overcome this bottleneck, we combine a sparse voxel structure with FlexiCubes. This allows us to concentrate computational capacity where it matters most, enabling efficient, high-fidelity recovery of complex geometric details.

Previously, most approaches relied on a single model to generate the complete 3D result all at once. We use a coarse-to-fine cascade. The initial stage focuses on generating the correct basic shape without worrying about intricate details. Subsequent stages progressively refine the geometry from coarse to fine, ultimately producing a highly detailed asset.

This is the Tripo 3.1 HD model. It supports a wide range of use cases, from high-end game assets to highly detailed 3D printing. With less fixing and more creating, it turns our research into a tool that creators can use.

Detail alone is not enough. We also need to know which parts should be separate and ensure that they fit back together. When a model is divided into logical components, 3D printing becomes much easier and more reliable. It requires fewer supports, enables better placement, and produces higher-quality surface finishes. It also simplifies post-processing because each detail can be painted individually before the components are snapped together.

Tripo Segmentation V2 was created for exactly that purpose: cleaner parts, complete control, and instant assembly. We are creating truly production-ready 3D assets—built to come apart and designed to fit back together perfectly.

Looking at the result on a screen is one thing. What about holding it in your hand? A 3D printer does not accept pixels; it requires real geometry, real dimensions, and parts that actually fit. The model leaves the screen, but the creative process continues. For a maker, this is no longer just a model; it is something they can make. All generated. All printed. All real.

For machines.

Can we teach a robot to pour tea?

Large language models have the internet. They have trillions of words and tokens from which to learn. But if we want a robot to learn by doing, there is no internet of practice.

Robots learn through interaction, and for that they need worlds. Here is a strange fact: not a single video on the internet contains a door that a robot can actually open.

We therefore build places where agents can learn. Everything is generated: kitchens, laboratories, warehouses, and living rooms. Each environment is different. Each can be entered, explored, and interacted with. No human team is going to build 10,000 kitchens by hand.

At this scale, something changes. These objects stop being merely assets and begin to behave more like words. A simulator does not care whether an asset is pretty; it cares whether the asset works. Simulation is not only about rendering—it is about behavior.

For that, we need four things: a visual mesh, a collision mesh, joints, and physical properties such as mass and friction. The parts, the rigs, and the structures turn a generated asset into something a simulator can actually use. These assets can be brought into simulators such as NVIDIA Isaac Sim or Gazebo.

The pipeline begins with a prompt—a sentence—and a few minutes later, a kitchen appears. You can open the cabinets and slide the drawers. We are not only generating assets; we are generating interactions. The robot then begins practicing—opening doors and picking up objects repeatedly across thousands of different environments. Worlds multiplied by tasks multiplied by demonstrations: diverse worlds produce diverse practice, and that is how we build experience at scale.

The Next Frontier: World Models

This could be the end of the story. For the player, the maker, and the machine, the test holds. But there is one more challenge.

We often hear about video models and world models. Consider a scene where frames are being re-rendered live by a video model. The model is reimagining each new frame as the scene unfolds. Some people call such systems world models. But the Teapot Test has one more challenge: look away, and then look back.

If a system forgets the past, objects drift or vanish because the entire history exists only in the pixels. If the world remembers, but nothing truly changes, it is incomplete. One system forgets the past; the other cannot create a new future. A real world needs both.

A world model is not merely a video model with better memory. It is a model of the world itself. States, objects, actions, and consequences must continue to exist whether or not you are looking at them. An image is only a view into that world. This brings us back to the distinction with which we began: looking and making are very different challenges. We have become very good at looking, but we are only beginning to learn how to make.

These demonstrations come from Project Eden, our research preview. First, there is a fire. The player picks up an extinguisher and puts it out. This is not a visual effect that disappears when the frame moves on. The fire is out, the world has entered a new state, and that change persists.

The second demonstration involves a wall. A player spray-paints "VAST" onto it. The mark remains in the persistent state of the world model. Any player who enters the world after us will inherit that wall. This is a persistent consequence.

Because the state is real, it can be shared: two cars on one track, with each player looking through a separate camera at a single synchronized race; two players exploring the same world from different sides. In a water-gun range, players shoot at the same targets, and the world scores them according to the same rules.

No one wrote a separate synchronization layer for any of these examples. Multiplayer is not a feature bolted onto the system; it emerges naturally from a shared, real state, just as it does in everyday reality.

Conclusion

Let us return to where we began. In 1975, the first widely recognized 3D reference model was itself a test. Newell measured his teapot by hand and built it to test whether machines could show. Fifty years later, the same object tests whether machines can make.

In 1975, one teapot measured by hand helped teach machines to see. In 2026, machines make the objects themselves. The object becomes matter: out of a sentence, into an engine, out of a printer, and into the physical world.

The teapot can be used in a game. It can be printed. A robot can learn from its digital twin. And when you look away, it will still be there.

Newell had to measure his teapot by hand. You will not have to measure yours. Let us build them.

Everything discussed here is real, and available today. The platform is tripo3d.ai, and developers can build custom workflows via our OpenAPI platform at https://developers.tripo3d.ai. The open-source projects, code, and model weights are available on GitHub and Hugging Face.

Now go make things.