Generate and retarget human movement while authoring a physical-AI scenario, then package the result as reusable motion assets for repeatable evaluation runs.
A simulated person rarely needs only one walk cycle. A test may require the person to move between locations, stop, turn, wait, resume, or cross a robot’s path. With a canned animation library, each new gait, pace, body, and transition adds more clips and more state connections to maintain.
Uthana provides another authoring path. Generate motion with Uthana’s models, retarget motion you already have, and prepare the resulting clips for the characters and states in a scenario. The output remains an inspectable motion asset rather than behavior that can run only inside Uthana.
This does not replace the simulator’s scenario system. The simulation still decides where an agent should go, when its state changes, and how it responds to the environment.
Simulation authoring and simulation execution place different demands on a motion system. During authoring, a team can request motion, inspect it, retarget it, and revise the scenario. Once approved, the motion can be baked into the character or scenario package and reused across repeatable runs.
That division is well suited to physical-AI evaluation. A team can spend time preparing the intended human behavior once, then execute the same condition repeatedly in local, automated, or headless workflows without generating the motion again during every run.
Uthana’s current production path is file-based authoring through its products and GraphQL API. It is not an embedded real-time simulation runtime.
Physical-AI teams often need more than one canonical pedestrian. They may want to test the same scenario with different movement styles, speeds, directions, motion sources, or character proportions.
Uthana can generate flat-ground locomotion from supported controls and retarget motion across compatible character skeletons. Existing customer motion can also be retargeted, so a team does not have to replace its current library to begin evaluating the workflow.
Variation creates additional test conditions; it does not prove that a perception system, policy, or robot becomes more robust. Downstream performance remains something the customer measures in its own evaluation stack.
The simulator should remain responsible for route planning, event logic, obstacle handling, and state changes. Uthana provides motion for those prescribed states and transfers it to the target character.
This boundary makes the integration easier to reason about. The simulation supplies a requested action or locomotion state. Uthana returns a motion asset. The customer’s tooling validates, packages, and triggers that asset inside the scenario.
Uthana does not currently interpret scene geometry, choose a collision-free path, or adapt feet and hands to arbitrary terrain and objects as a general production capability.
Current self-serve output is FBX or GLB. Uthana does not currently provide native USD output, environment-aware navigation, varied-terrain locomotion, hand-object interaction, or a production embedded simulation SDK.
Simulator-native packaging, target-stack adapters, embedded runtime use, additional output formats, environment-aware motion, terrain interaction, and object interaction may be evaluated through a scoped design-partner engagement. Availability is confirmed for the specific pilot rather than offered as a standard product claim.
A useful pilot begins with one representative character, one scenario sequence, the current motion source, and the exact asset package the simulator consumes. Uthana and the customer can then test generation, retargeting, conversion, review, and execution without assuming a broader integration already exists.
Bring the target skeleton, sample motion, required output structure, scenario states, execution model, and acceptance checks. Uthana will identify what works through the current file-based workflow and what would require scoped co-development.
No. The simulator remains responsible for routes, behavior, obstacles, and scenario events. Uthana provides motion for prescribed actions and locomotion states.
The current workflow is to generate and retarget motion during authoring, then package approved motion assets for repeated or headless execution in the customer’s stack. Uthana is not a production embedded runtime.
Not natively today. Current self-serve motion outputs are FBX and GLB. A customer may convert and package those assets in its existing pipeline, or discuss additional format work as part of a scoped engagement.
Not as a general production capability today. Current locomotion is for flat-ground movement. Terrain-aware motion would require scoped technical work.
Yes. Uthana can retarget compatible customer-provided motion, allowing a team to test the workflow without replacing every existing clip.
Uthana is not naming tested simulator integrations at launch. Technical fit is evaluated against the customer’s target skeleton, asset format, packaging, and execution requirements.
Start generating motion today, or work with us on a custom dataset, embodiment system, or simulation program.
