Generating a cup that can survive a drop is harder than generating a good-looking one

As someone who knows absolutely nothing about this, I tried Shunshi Technology's physical asset generation. The name is pretty straightforward—it falls under the "world model" category, meaning it lets AI generate 3D objects, and these objects have to obey physics: they have mass, friction, they roll when dropped—not the kind of model that's just for looking at.

This is a bit like the protein structure prediction I usually do—sequence in, structure out, and that middle layer of physical constraints is where the real skill lies.

Day one: the interface wasn't hard, what was hard was not knowing what to describe. Signing up didn't take long; inside there's an input box and a few parameter panels. My initial idea was very simple—I typed "a white mug, ceramic material, placed on a table" and hit generate.

The result looked good, the glaze reflections were all correct. But when I dropped it into a simulation to test, the wall thickness was random, the center of gravity floated above the rim, and it tipped over as soon as I let go.

I stared at the screen for a long time before it hit me. I described the appearance, it gave me the appearance—I hadn't said a single word about the physics part.

Later, going through its workflow, I understood: this kind of tool generally works in two steps—first understand the physical constraints you give it, then generate geometry, texture, and kinematic parameters. That PhysForge paper from HKU and Tencent Hunyuan follows this approach: a VLM does the physical planning, a diffusion model handles the implementation, and they even built a library of over a hundred thousand assets to support it. Sounds complete, but in actual use, the input for the first step depends entirely on you thinking it through clearly.

By day three, I was gradually learning to write prompts. I changed my wording, wrote in mass, friction coefficient, collider shape, and even directly wrote "wall thickness 3mm, center of gravity in the lower third of the body." The pass rate visibly went up.

Over these few days I've picked up a few lessons. State the purpose first, then the appearance—writing "needs to be graspable by a robotic hand" is far more useful than writing "needs to be exquisite." Don't be lazy with colliders—the default convex hull is basically unusable for hollow objects like a mug. After exporting kinematic parameters, always run it back through simulation—on my end, about one in five times a joint axis is reversed. When batch generating, fix the physical description template and only change the appearance—don't rewrite it every time.

Its most valuable aspect is turning physical properties into editable fields—this is more mature than I expected. But it won't think about the physics for you. If you say it wrong, it follows along, and does it quite beautifully.

After a week, here's my judgment. Recommended, but depends on the case.

Suitable for teams building embodied AI simulation scenarios, especially those needing large batches of long-tail objects—like preparing a thousand unfamiliar everyday items for a robotic hand. In this scenario, it saves the modeler's time, not their brainpower.

Not suitable for two types of people. One is those needing millimeter-level precision assembly—it can't give CAD-level tolerances. The other is those who think typing one sentence is all it takes—you'll get a pile of pretty junk.

On the trend, I'll bet on one thing. Physical asset generation won't exist standalone for long; it'll be absorbed into simulation platforms as an upstream component. UBTECH's Thinker-Sim is already doing the full pipeline of scene reconstruction plus automatic asset generation—whoever stitches generation and validation into one loop first wins. Selling a generator alone has limited value.

There's a gap between dry lab and wet lab, and there's a gap between simulation and real machines—this gap is currently stuck mainly at the asset layer.