Inconsistent third-person right rotation semantics between prompt_builder.py and HY-WorldPlay pose generation

[sysuKaiYang]

Hi, thanks for open-sourcing WBench.

I noticed a possible inconsistency in the third-person navigation semantics for right rotation.

What I found:
In src/models/text/prompt_builder.py, the third-person action mapping says:
left: The camera orbits counterclockwise around the subject.
right: The camera orbits clockwise around the subject.

However, in the HY-WorldPlay adapter path:
examples/hy_worldplay/convert_cases_to_jsonl.py maps right to yaw = +1
examples/hy_worldplay/navigation_to_poses.py updates orbit angle with:

if "yaw" in move:
    azimuth -= move["yaw"]

with initial azimuth = np.pi.

From this logic, for third-person orbit mode, right makes the camera move counterclockwise in top-down view, not clockwise.

Questions
Is prompt_builder.py using incorrect wording?
Or does HY-WorldPlay use the opposite orbit convention from the text prompt definition?
If the adapter behavior is intended, should the prompt text be updated to avoid confusion?

[sysuKaiYang]

Additionally, I found completely contradictory conclusions in the appendix figures. In Figure 12, the third-person → is defined as counterclockwise; however, in Figure 16, the GT trajectory for [W → Right → Right → Left] actually moves clockwise. Similarly, in Figure 15, Happy Oyster and HY-World 1.5 — which move clockwise — are labeled as correct, while HY-Video-1.5 — which moves counterclockwise — is labeled as incorrect. Which direction should I actually use as the correct execution logic for third-person rotation?

[KainingYing]

Thanks for the detailed report!

The generation code is correct — you can follow this pipeline as-is to generate, for both the camera-pose and text-prompt paths; they're consistent and produce the intended third-person viewpoint, with left/right orbit behaving as expected in the rendered videos. So there's no bug in the actual generation.

You're right that Figure 12 has the rotation direction reversed — that's the source of the apparent contradiction with Fig. 15/16, and we'll fix it in the next revision.

To be honest, we're a bit confused about the trajectory direction convention ourselves, so we're actively looking into it (pose adapter vs. eval GT vs. prompt wording) and will follow up here once we've confirmed it end-to-end. Thanks again for flagging this!

[sysuKaiYang]

Thanks for the reply! Would it be possible to share the video generation results from your leaderboard?

[KainingYing]

Of course, we have open-sourced part of it.

https://huggingface.co/datasets/Kaining/WBench-examples-open/tree/main
https://huggingface.co/datasets/meituan-longcat/WBench-examples