Quo Vadis, Motion Generation? From Large Language Models to Large Motion Models

Authors: Ye Wang, Sipeng Zheng, Bin Cao, Qianshan Wei, Qin Jin, Zongqing Lu
Primary area: generative models
Keywords: human motion generation, large motion model, large language model

Abstract:
Inspired by the recent success of LLMs, the field of human motion understanding has increasingly shifted towards the development of large motion models. 
Despite some progress, current state-of-the-art works remain far from achieving truly generalist models, largely due to the lack of large-scale, high-quality motion data. 
To address this, we present MotionBase, the first million-level motion benchmark, offering 15 times the data volume of the previous largest dataset and featuring multimodal data with hierarchically detailed descriptions.
By leveraging this vast dataset, our large motion model demonstrates strong performance across a broad range of motions, including unseen ones.
Through systematic investigation, we underscore the importance of scaling both data and model size, with synthetic data and pseudo labels playing a crucial role in mitigating data acquisition costs.
Moreover, our research reveals the limitations of existing evaluation metrics, particularly in handling out-of-domain text instructions --- an issue that has long been overlooked.
In addition to these, we introduce a novel 2D lookup-free tokenizer for motion quantization, which preserves motion information and expands codebook capacity, further enhancing the representative ability of large motion models.
The release of MotionBase and the insights gained from this study are expected to pave the way for the development of more powerful and versatile motion generation models.
Our code and database will be released at \url{https://anonymous.4open.science/r/MotionBase}.

Decision: reject
Reviewer scores: 8, 6, 6, 5, 5

Reviews and discussion:
<thread>
creation date:
1729049561581

thread_type:
official_review

<thread_object>
creator: reviewer_wfz5

<content>
summary:
This paper claims to propose a large motion model with a very large motion database. However, the motion quality is not well evaluated. Besides, the authors propose a motion quantization method, which is borrowed from LFQ (Mentzer et al., 2023). The authors claim a good generation quality of the generated results, which is not provided in the demo.

strengths:
- The writing of this work is a bit fancy. 

- The statistics of the dataset are clear.

weaknesses:
There are several fundamental concerns about this work. Each of these is fatal. 

1. **The motion collection process.** This process contains several issues. 
    - This work does not evaluate the quality of the video mocap data quality. To my knowledge, even the quality of the latest Motion-X++ suffers significant jittering and foot sliding. How can your method escape from this? **(my main concern)**
    - If the quality of the ground truth is not good enough, how can you generate good motion? Therefore, the result in L395-402 is not solid and convincing. **(my main concern)** I suggest authors read the blog [1] written by a well-known graphics scientist, Daniel Holden. 
    - The limited contribution of the dataset. The video data comes from InternViD and WebVid and the data collection process is from motion-x and other methods. The dataset contribution is limited. 

2. **The text annotation.**
    - The annotation quality of the text by Gemini-1.5-pro is not well evaluated. In my practice, it always contains some answers like "sorry...". The results should be corrected by researchers one by one. Has the >1M data been checked? 
    - The proposed contribution of hierarchical text is not discussed well. Has it been used in the model training? If I miss, please point it out. If this annotation is not used, what is the motivation for this hierarchical text contribution? Will it make the result more fine-grained? It is quite unclear. **(my main concern)** 

3. **Limited technical/evaluation contribution.** The LFQ is proposed by the original paper. The authors did not have a new understanding over this. Besides, the H2VQ proposed in Humantomato (ICML-24) is also missing for discussion or comparison. 

4. This work does not include any demo video, which is unacceptable in the animation community. The FID in Table 5 is extremely large, which strengthens my concerns about the motion quality. 

5. **Motivation.** The motivation for introducing LLM is not clear. The method misses a basic baseline of a transformer (like in T2M-GPT, CVPR-23) for comparison. Besides, it is also not clear whether the usage of pre-trained parameters of LLMs or not. Whether the fine-tuning method is LoRA or not is also not well discussed. Therefore, it is not technically sound. **This is my strong concern.**

[1]: Daniel Holden, https://theorangeduck.com/page/animation-quality.

questions:
- The vocabulary of the LLM and motion codebooks are different. How do authors handle this issue? What is the efficiency of the LLM-based motion generation method? Please compare with the fastest motion generation method, MotionLCM (ECCV-24).

- **I would like to know why authors should cite [1].**

[1]: Zheng et al., Steve-eye: Equipping llm-based embodied agents with visual perception in open worlds.
</content>
</thread_object>

</thread>
<thread>
creation date:
1730443623557

thread_type:
official_review

<thread_object>
creator: reviewer_qpup

<content>
summary:
This paper collects a new large-scale text-motion dataset called MotionBase and then finetunes LLMs with different sizes. Additionally, for better scaling, the authors follow the video domain to train a new LFQ tokenizer with a large vocab size.

strengths:
1. The authors try to scale the tokenizer vocab size and the model size.
2. The authors collect a new large-scale text-motion dataset.

weaknesses:
1. The biggest server weakness is containing the one-frame pose data into the database. The Agora, mscoco, muco_3dhp, and other more datasets are used for 3d pose estimation, and they even occupy a large portion of the whole database, which may lead to static motion generation. 
2. The motion quality has not been validated. Neither the estimated motions nor the texts generated by LLM have been checked manually or by any algorithm. The video collection process is not clarified clearly. A lot of web videos are long and contain various camera shots. Which film shot boundary detection algorithm are you using? And how many frames do you insert into LLM to get the text? More details need to be added. 
3. The experiments with static data ablation study are not fair. Does the validation set contain static data and synthetic data?

questions:
1. The FID in Table 6 is so wired. The FID of reconstruction is 1.76 while the generation FID in Table 3 is 0.166. This is impossible from my understanding. I suspect that the reconstruction result is not good enough. The original MPJPE calculation will subtract the root movement. If you calculate MPJPE similarly, the high reconstruction FID means the translations are not accurate. 
2. What do the authors get from scaling experiments? Did the author see any hope for emerging? The shown examples are common cases, that can be also observed in other motion generation work.
3. Did the supervised label contain only motion tokens or both text and motion tokens? 
4. Did the author try zero-shot text testing? For example, could the largest model do some texts like "The old man with a broken leg is walking forward slowly with a crane"?
</content>
</thread_object>

</thread>
<thread>
creation date:
1730595865141

thread_type:
official_review

<thread_object>
creator: reviewer_pt95

<content>
summary:
The paper is to answer the research question of "can a large motion model be a promising direction for motion generation?", and the designed a data colletion pipeline which collects multi-modal information including RGB, depth and bounding box with multi-person.
In addition the paper introduces a method to expand the codebook capacity, named lookup-free approach for motion tokenization, for better motion representation.

strengths:
This paper presents the first large-scale dataset specifically designed for motion generation, featuring richly multi-modal data accompanied by hierarchical text descriptions. MotionBase, the dataset introduced, is expected to be highly beneficial for the advancement of future research in motion generation and to serve as a valuable resource for the computer vision community. The dataset offers researchers access to an extensive collection of motion data, enabling more robust analysis and development of large motion model.

weaknesses:
I have minor concerns on this paper.

The layout of the paper is somewhat challenging for readers. It contains numerous messages and analyses, requiring readers to scroll up and down frequently to locate referenced tables. Additionally, due to page limitations, many explanations are placed in the Appendix. Tables and figures are positioned mid-page without aligning well with the paragraph height, disrupting the flow.

This paper was the first to introduce the concepts of partitioning body parts and 2D quantization, making it a valuable reference. (Pi, H., Peng, S., Yang, M., Zhou, X., & Bao, H. (2023). Hierarchical generation of human-object interactions with diffusion probabilistic models. In Proceedings of the IEEE/CVF International Conference on Computer Vision, pp. 15061-15073.)

Minor Issues and Typos:
Appendix D: "quantitative results" should be "qualitative results."
Figure 4: It may improve clarity to add a y-axis label.

questions:
In Table 4, what is the ratio between synthetic, static, and real data? It can be brefiely explained in table caption.

I have the concern of the quality of occlusion cases or blurred images. How the authors recognize the motion is blurred or occluded?
In multi-person settings, the occlusion might be very common.

Since this is a dataset paper, I expect the more detailed explanation and instructions of the benchmark will be released once the paper upon the paper acceptance.
</content>
</thread_object>

</thread>
<thread>
creation date:
1730713617967

thread_type:
official_review

<thread_object>
creator: reviewer_pqnv

<content>
summary:
In this paper, the authors introduce MotionBase, a large-scale human motion generation benchmark featuring over one million motion sequences, a fifteen-fold increase over previous datasets, with multimodal data and detailed text descriptions. The authors demonstrate that scaling both data and model size significantly improves motion model performance, particularly with synthetic data and pseudo labels to reduce data acquisition costs. The authors also propose a novel 2D lookup-free motion quantization approach to enhance motion information retention and expand codebook capacity. Experimental results on various datasets validate the efficacy of their approach, with notable performance on out-of-domain data.

strengths:
1. The paper introduces MotionBase, a large-scale dataset comprising over one million human motion sequences, designed to support more comprehensive training and evaluation of motion generation models.

2. The paper identifies key factors influencing the effectiveness of large motion models, underscoring the importance of scaling both data and model size.

3. This paper proposes a 2D lookup-free motion quantization method that enhances motion representation while retaining essential information, thereby contributing to improved model performance.

weaknesses:
1. While MotionBase is introduced as a benchmark with the potential to enhance motion model performance, the paper lacks a thorough comparative analysis across varied methods to demonstrate MotionBase's influence on model efficacy. Additional baselines and a broader selection of models trained on MotionBase would more robustly substantiate its claimed advantages.

2. The paper does not include visual comparisons of motions generated by models trained on the baseline Motion-X dataset versus those trained on the proposed MotionBase dataset.

3. Including the ground truth R-Precision and FID scores in relevant tables would strengthen the presentation and transparency of the results.

4. The paper would benefit from dynamic visualizations within the qualitative analysis of the motions in the proposed datasets, which could provide a clearer and more engaging illustration of the dataset's scope and quality.

questions:
1. It will be interesting to see the scalability of different architectures. Have the authors explored fine-tuning existing methods, such as MotionGPT[1] or MoMask[2], with larger parameter settings on the MotionBase dataset? 

2. Regarding the automated evaluation metrics referenced by the authors, it is also noteworthy that the R-precision scores are relatively low on the proposed large-scale MotionBase dataset, potentially weakening the benchmarking results. Implementing text-motion retrieval models like TMR[3] may provide a more accurate evaluation of model performance.

[1] MotionGPT: Human Motion as a Foreign Language.

[2] MoMask: Generative Masked Modeling of 3D Human Motions.

[3] TMR: Text-to-Motion Retrieval Using Contrastive 3D Human Motion Synthesis.
</content>
</thread_object>

</thread>
<thread>
creation date:
1730828657353

thread_type:
official_review

<thread_object>
creator: reviewer_ch9d

<content>
summary:
Paper introduce motionbase, a motion generation benchmark trained on large amount of data with focus on motion generation with LLMs.

strengths:
The work is well motivated in terms:
 Showing the gap of prior work and lack of domain generlization 
Showing limitation of prior metrics 
A new motion codebook 


The new dataset is quite large in comparison with prior ones, which is a valuable addition to the community. It comes with a good set of text descriptions. 

Evaluation on multiple datasets and multiple models with strong baselines.
Answer to important questions like the need of scale and model size impact on the task 
Discussion on OOD behaviour 
Ablation of motion quantization

weaknesses:
I do not see much of concerns about the work, more of questions.

questions:
– Questions:
How did the author verify the correctness/accuracy of the pose estimation
What do authors think about properties of a new metric?
</content>
</thread_object>

</thread>
<thread>
creation date:
1732313911208

thread_type:
official_comment

<thread_object>
creator: reviewer_wfz5

<content>
title:
reply

comment:
Thanks for your discussion. I have carefully checked reviews from other reviewers and checked the latest response. I think we still need some discussions. 

Before stating my comments, I would like to clarify that the significant revisions related to contributions are not supported officially, according to the review guidance. The review should be based on the original submission, not the major revision. Although there are these issues, I would also like to discuss more about them. Besides, external links are not permitted because this will not be track by the fair reviewing process. Why not use the supp.? 

1. For your motion-capturing process, what is the policy you use? PHC? RFC? ASE? For the statement “If a refined motion maintains balance in the simulated environment for a specific duration, it can be regarded as high-quality with no severe issues …”, what is the duration, and how to compute the success rate? What is your success rate? Besides, how do you deal with videos with shot cuts? 
2. I also noticed reviewer `qpUP` has similar concerns on static motions. I think the data is the pose, not motion or animation. Our animation community does not recognize the pose as motion. When the data distribution includes such data, it will be harmful to your generation results. I have also provided the blog by Daniel in my previous review. 
3. The video demos on the website are not friendly for usage. Please provide them in supp..
4. For the Gemini-score from 1 to 5, how can the method be fair enough to evaluate whether the texts are aligned with motion? With motion input?
5. For the hierarchical text issue, is your evaluator trained with hierarchical text? Why is the R-P of generated results higher than GT?
6. Why do your results of `Hierarchical`and `Full Param`are not the same in response? I do not see the result of T2M-GPT as a baseline in the response.
7. I am still a bit curious about citing reference [1]. Which part of reference [1] did the authors refer to?

Besides, I did not see any revision in the manuscript. (w/o any highlights)

Up to now, I will temporarily keep my rating and wait for replies from other reviewers. If any point of my review or statement is wrong, please directly point it out. This will help us to clarify issues.
</content>
</thread_object>

</thread>
<thread>
creation date:
1733147480851

thread_type:
official_comment

<thread_object>
creator: authors

<content>
comment:
**Dear reviewer WfZ5**,

Thank you for your unique and valuable feedback. Inspired by you, we believe it would be beneficial to include our response in the top general response, allowing other reviewers and AC to easily access it due to the lengthy reply history. After this extensive journey of rebuttal, we sincerely hope to reach a final conclusion.

1. To answer your first question. You mention "how can it be generalized to the motion you captured?". However, we do not claim a generalizable PHC with 100% success rate from the beginning. Instead, our goal is to present PHC as an additional technique compared to MotionX [1] and Holistic-Motion2D [2], which also rely on pretrained models to extract motions from videos without any physical-plausible refinement. Compared with them, our approach achieves 30% more physically plausible motions, effectively reducing jittering and sliding artifacts. **We believe this makes our dataset a self-stand contribution, otherwise all other works using pretrained models to extract motion without physical-plausible refinement, would become of no value.** Considering this, we argue that an ideal method you are expecting is another large topic [3] which obviously falls outside the scope of this paper.
2. The details of the static data ablation can be clearly found in L435–L438 and L1049–L1059, with the marked title **"TRAIN SET w/o static data"** clearly indicating the relevant settings. The test sets used are MotionBase-test and MotionBase-test w/o static/syn, as described in L1055. In both test sets, using the complete MotionBase dataset significantly outperforms the "w/o static data" configuration. I do not know why you can not see it. We also note that no other reviewers, apart from you, have raised similar questions, suggesting that the provided setting details should already be sufficiently clear.

In addition to this, for the static pose:
  - We show its effectiveness through our experiments in Table.4 and Table.8
  - We emphasize once again that static data serves as a bonus to our dataset contribution. MotionBase already includes 800K dynamic motion samples—10 times more than previously available datasets.
  - We note that the reviewer has overlooked several important references despite claiming being familiar with motion and LMM community. To assist with the reviewer's evaluation, we kindly provide some references for better judgment. Reference [4], for example, has already demonstrated that static data can smoothly produce whole-body and hand poses in a video. Many well-known works in motion and keypoint [5][6][7] heavily rely on well-pretrained backbones using static pose (e.g., COCO) or directly incorporate static pose during training. **These works consistently validate that static pose contributes positively to smooth generation and poses no harm**. We strongly recommend the reviewer consult these officially published and well-known works and their repositories, rather than relying on unofficial blogs as evidence.  As a specialist of LMM, we believe the reviewer can readily appreciate the paradigm of using static and dynamic data for pretraining and dynamic data for fine-tuning. 
  - We kindly point out that the reviewer’s statement is not entirely accurate. No other reviewers except you have raised further concerns about static data following our earlier responses.
3. We believe the supplementary material is accessible, as we successfully downloaded the file from OpenReview using various IP addresses across different locations worldwide. All attempts were successful, except for your instance. 
4. We are so puzzled by this feedback, as the robot demo was only included in the supp file and was not presented as a contribution in the main paper ever. **It is concerning when a reviewer misrepresents our stated contributions by suggesting**: "I think a better choice is to include it in the appendix" or suggesting, or "If you emphasize this too much, reviewers will treat this as your unique contribution seriously." **These words definitely go against our statement, which risk misleading the AC or other reviewers, potentially creating misunderstandings about our work.** In fact, we provided the demo to all reviewers, and none of them raised similar concerns.
5. **We are quite puzzled that the reviewer has focused on the word "independently" while overlooking the initial word, "Firstly."** As clearly stated, we have two approaches for evaluation: one is text-only, and the other is vision-text. "Firstly" refers to the first approach, while "More important" introduces the second. In our response (22 Nov 2024, 21:03), we had already clarified this by using clearer numerical markers (1..., 2...) to enhance readability. Notably, this explanation was also shared with reviewers qpUP and pt95, neither of whom expressed any misunderstanding.
</content>
</thread_object>

</thread>
<thread>
creation date:
1733190868339

thread_type:
official_comment

<thread_object>
creator: authors

<content>
comment:
Dear reviewer WfZ5,

This is the reviewer guidance on ICLR 2025 official website. We sincerely note that ICLR's rebuttal phase is different from most other AL/ML comminuty: https://iclr.cc/Conferences/2025/ReviewerGuide#Reviewer%20tasks. If you are the first time to serve as ICLR's reviewer, you should really  read the guideline carefully first. Otherwise, your conclusion may disobey the traidition and spirit of our ICLR community.

**Engage in discussion: The discussion phase at ICLR is different from most conferences in the AI/ML community. During this phase, reviewers, authors and area chairs engage in asynchronous discussion and authors are allowed to revise their submissions to address concerns that arise. It is crucial that you are actively engaged during this phase. Maintain a spirit of openness to changing your initial recommendation (either to a more positive or more negative) rating.**

In what context does this paragraph suggest that the reviewer should base their evaluation on the "initial paper"?

We are quite puzzled where do you get the information that "a reviewer's decision should base on the original version". As a ICLR reviewer too, I saw many reviewers appreciate the revision of the author and change. If the reviewers do not follow the ICLR's spirit, it would be quite unfair for our paper's rebuttal.

In addition to rebuttal guidance, we have the following concerns that we believe should be clarified first:

  - For PHC and other details: the reason we provide so much details about PHC is because you ask the corresponding questions. The PHC's role is only a sentence in our initial paper, not a major part. **Once again. we concern the reviewer mistakenly represent our contribution.**
  - For static data: Do we have any approach to convince you in addition to experimental results and codes we provided?
  - Most importantly, we raise the **logical questions**: Based on your feedback, do you believe the paper would be improved by removing all of our static data and corresponding experimental results? Doesn’t this suggestion seem somewhat unreasonable? Additionally, do you recognize the contribution of the dynamic part of MotionBase? If you believe the static data is more problematic, then the dynamic data should be of higher quality to compensate, right? Otherwise, how would the results improve? 


Finally, we believe it’s not productive to judge the tone of others. This could serve as a subjective hint to the AC and other reviewers. If any of our words stray from the matter at hand, please point it out. Otherwise, it risks being an unfounded accusation.

Best,

Authors
</content>
</thread_object>

</thread>
<thread>
creation date:
1733192050594

thread_type:
official_comment

<thread_object>
creator: authors

<content>
comment:
Dear AC/PAC/PC,

For the long time during ICLR's history, we believe ICLR allows authors to revise their papers in response to reviewers' concerns. However, we are now concerned about potential misunderstandings regarding the rebuttal phase, as some reviewers may be confusing ICLR’s rebuttal process with that of traditional conferences. **The spirit of ICLR is the only reason we have been willing to provide such detailed responses before the official release of our paper (over 30 ICLR pages in rebuttal), especially given that we initially submitted a content-rich version (over 25 ICLR pages).**

Some reviewers have suggested that "major revisions are not worthy of consideration in the review process" and that "basing a decision on revisions would be unfair to other papers." We would appreciate clarification from the AC, PAC, PA on this matter, as we’ve noticed that one of the main reasons reviewers have not raised their scores is their belief that the decision should be based solely on the original version of the paper.

For reference, here is the reviewer’s guideline on the official website:
 
**Engage in discussion: The discussion phase at ICLR is different from most conferences in the AI/ML community. During this phase, reviewers, authors and area chairs engage in asynchronous discussion and authors are allowed to revise their submissions to address concerns that arise. It is crucial that you are actively engaged during this phase. Maintain a spirit of openness to changing your initial recommendation (either to a more positive or more negative) rating.**

This raise another question we wonder: if the reviewer suggest "the decision should base on initial version", why do they ask so many questions refering to our data construction details (65 reply so far)? The level of detail we have provided has become so extensive that reviewers might mistakenly consider it the paper's main contribution. To our knowledge, no other works (e.g., MotionX, Smpler-X, EgoBody) have released such extensive details, even after their official publication.

In addition to this, another concern is about the static data. We have provide experimental results to validate our proposal. If the reviewer does not believe the results, we also provide corresponding code, checkpoints. If the reviewer overlooks the results and code we provided and relies on subjective experiences alone to draw conclusions, how can we convince a reviewer?

Best regards,

Authors
</content>
</thread_object>

</thread>
<thread>
creation date:
1733215628674

thread_type:
official_comment

<thread_object>
creator: authors

<content>
comment:
Dear reviewers, 

We sincerely appreciate the time and effort each reviewer has dedicated to this discussion. However, with the rebuttal deadline approaching, there are still some remaining questions that we believe should be addressed.

Before raising these questions, we want to clarify an important point: Why do some reviewers perceive the level of detail we provide as resembling a major revision?  **In fact, we are also puzzled by this. We suggest after several rounds of rebuttal, some reviewers may have mistaken minor aspects of our work for major contributions.**
For example, reviewer WfZ5 thinks we emphasize too much about robot demos. Here is a brief rebuttal summary of this point (**if anything of the following is wrong, please feel free to point it out**):
- Q: We need a recorded video. 
- A: Sure, we made a website for you.
- Q: The external link is not allowed, you should provide a supp file to OpenReivew
- A:  OK, we provide the zipfile that contains all demos in the website.
- Q:  Is it challenging for you to concatenate them in a video?
- A:  Sure, we concatenate our demos and update the supp file once again.
- Q:  The resolution is too small, details can not be seen.
- A:   OK, we provide a higher-resolution video for you.
- Q:  Why do you hang the robot in your robot demo?
- A:  The robot videos are only demos.
- Q:  The author should not emphasize too much about the demo. If you emphasize this too much, reviewers will treat this as your unique contribution seriously.

After addressing the reviewer's questions **about demos**, we believe they may have received an overwhelming amount of information from us, potentially leading to the mistaken impression that the robot demo is a significant aspect of our work. **In fact, we do not even discuss it in the main paper.**  This misunderstanding occurred multiple times during the rebuttal process. For example, PHC is a technique proposed by others, and we use it only as one of the methods to refine our data, which is briefly mentioned in just 1–2 sentences in our paper, just like most previous works (e.g., HumanPlus, MotionX). However, during the rebuttal, we provided two pages of detailed explanations about PHC. As a result, the reviewer mistakenly regarded it as a central aspect of MotionBase, **which we have never claimed.**

Finally, we want to go back to our remaining questions, which we believe are important to draw a conclusion:
- Does reviewer suggest the ICLR's rating should at least consider the revised paper according to the spirit of ICLR?
- Do you believe our experimental results, or our code, checkpoints? If you do, why do you still have concerns about static data? If you do not, what else do we need to provide? Is there any possibility to convince you?
- The original dynamic data is near 400K, almost 5 times larger than before. The revised version is 800K, 10 times larger than before. If the reviewer is not convinced by static data, do you recognize the contribution of our MotionBase? 
- If the reviewer thinks static data is harmful, do you believe that our dynamic data should have higher quality? This should be a conclusion that can be reached simply through logic.

Best,

Authors
</content>
</thread_object>

</thread>
<thread>
creation date:
1733310779756

thread_type:
official_comment

<thread_object>
creator: authors

<content>
title:
Summary of the rebuttal

comment:
Dear AC and reviewers:

We deeply appreciate your efforts during the rebuttal process. We are encouraged that reviewers CH9D, phNv, and pT95 recognize the value of our work. Reviewer qpUP believe our paper would be a good paper with the inclusion of revised details during rebuttal, though their review, along with WfZ5's, is borderline reject. To address our lengthy and fragmented discussion with WfZ5, we provide a brief summary below.

--- 
# Our work in brief
We propose to construct a large-scale motion generation dataset, validate the scaling law in motion understanding, and explore motion tokenization. The importance of contributions is ranked in order.

--- 
# Reviewers' positive recognitions
* **From reviewer CH9D**: 
  - well motivated
  - dataset is large
  - Evaluation on multiple datasets and multiple models with strong baselines.
* **From reviewer phNv**:
  - propose a large-scale dataset 
  - identifies key factors influencing the effectiveness of large motion models
  - explore effective motion quantization method

* **From reviewer pT95**:
  - the proposed large-scale data has the potential to be a valuable resource for the community

* **From reviewer qpUP**:
  - collect a new large-scale text-motion dataset.
  - scale the tokenizer vocab size and the model size.

* **From reviewer WfZ5**:
  - good writting
  - The statistics of the dataset are clear.

# Remaining points:

**Should the revised details be considered during rebuttal?**

We emphasize that the spirit of ICLR motivates us to share extensive details of our work, including code, checkpoints, and demo —— something few other papers do before official publication. The unique spirit of ICLR, which fosters open discussion, is what sets it apart from other conferences. Since some reviewers may be attending for the first time, we hope the AC, Senior AC, and PC will remind them of this. If reviewers insist on statements like:
> "the discussion process is for addressing misunderstandings in the reviews, not for providing major revisions. "

>  "basing a decision on revisions would be unfair to other papers"

>  "These details are supplemented during the rebuttal period. This is unfair to other submissions."

  Our efforts to share will be in vain. We feel discouraged and disheartened by these comments, especially after receiving appreciation in previous ICLR submissions. We are even restricted from using anonymous links to share our code, checkpoints, and demos. As reviewers ourselves, we’ve seen other papers praised for their revisions. If our revision is disregarded, it would be unfair. For reference, here’s the reviewer guideline from the official website:

  > "Engage in discussion: The discussion phase at ICLR is different from most conferences in the AI/ML community. During this phase, reviewers, authors and area chairs engage in asynchronous discussion and authors are allowed to revise their submissions to address concerns that arise. It is crucial that you are actively engaged during this phase. Maintain a spirit of openness to changing your initial recommendation (either to a more positive or more negative) rating."

**WfZ5 considers some points as major revisions, but we disagree.**

The details during rebuttal do not go against our original paper. For example:
  - WfZ5 labels PHC as a significant revision, but we never claimed that; it's just one step in a broader data refinement process.
  - WfZ5 argues we overemphasize the robot demo, which we did not claim.
  - WfZ5 views increasing dynamic data from 400K to 800K as a major revision, but we question this; the original 400K clips with over 1M motion-text pairs are already  self-standing.
  - A major revision should be defined as something goes against our contribution to the original paper. Asking eight questions about a small step in the pipeline, such as implementation details, reward setup, or success rates, cannot be considered a major revision.

**Is Static data harmful?**
- We provide experiments, code, pretrained models, 100+ demos, and related work, yet the reviewers remain unconvinced. Additionally, we find some feedback from WfZ5 to be subjective:
    - WfZ5 states, "I think this is not a suggested choice in the animation community," which is a biased conclusion. How can motion generation be limited to animation, ignoring applications in vision, robotics, and VR/AR?
    - WfZ5 recommends reading an unofficial blog by Daniel Holden, claiming "you will find it not self-stand if you read this well-known scientist's blog." After reading it, we found only empirical suggestions. Using this as evidence to question our results contradicts scientific principles, which should be based on truth and experimental evidence, not empirical opinions.
- This opinion leads to a logical contradiction: if static data is harmful, dynamic data should be of even higher quality. Otherwise, how could our results improve?
</content>
</thread_object>

</thread>


Metareview:
metareview:
The submission proposes MotionBase, a large-scale dataset of human motion, as well as methods that aim to develop a large motion model.  The submission received mixed feedback before and after the rebuttal, with long, extensive, and somewhat intense discussions.  The AC read the submission, reviews, rebuttals, and discussions. 

The positive side of the submission is the usefulness of the dataset and the additional evaluation.  The concerns are about the use of static frames, as well as the possibly "major" changes during the rebuttal.  The AC agreed with the authors that links can be used and changes are allowed during rebuttal; meanwhile, the AC would also like to acknowledge that reviewers are indeed allowed to ignore changes if they are considered too major.  Whether the changes are major is mostly a subjective decision, and people may have different opinions.

The AC carefully reviewed the submission and the anonymous link to better understand the dataset and technical contributions.  The AC found the quality of the demos below expectations, with missing documentation and unclear visualizations.  The authors are encouraged to thoroughly revise the submission to significantly improve the presentation of the main paper, supp, and video demos for the next venue.