Techniques for Skeletal-Based Animation in Massive Crowd Simulations
Round 1
Reviewer 1 Report
Please see the uploaded marked manuscript for most of my comments.
I disagree with the statement on page 8 "Note that the offset change rate per simulation frame is fixed for all agents, so it looks like all agents are moving at normal speed." In fact, the offset changes linearly in time, so that in the context of beginning a celebration, characters will start out moving more slowly than normal, until their delay behind the animation stream increases to the desired offset, and then move at normal speed from then on. I think that this will look strange, and it would be better to have the characters just wait to begin their celebration motion until their desired offset time has elapsed. Therefore I think that this time dilation feature should be removed from the paper.
Comments for author File: 
Comments.pdf
Author Response
- All comments in the marked manuscript uploaded were addressed in the final paper.
- Related to the statement "Note that the offset change rate per simulation frame is fixed for all agents, so it looks like all agents are moving at normal speed." :
Let us first argue why time dilation is technically necessary. If you jump from an idle to a celebration animation and the maximum offset is, say, 2 seconds, imagine that there are parts of the crowd that could possibly react to a goal only after 2 seconds! In practice, in visualizations, this would look very strange, as if people had a mental problem or something :)
Second, on the note you observed, we still think that the text is written, but let us explain it in more detail.
If you look at the explanation and pseudocode below where we calculate A.rate, you can see that the same rate of change is actually applied to every character that belongs to that particular animation stream. So all characters using the same animation stream A will use the same speed, regardless of whether their current offset is 3, 5, or 20 frames.
You can imagine that time dilation acts as a fast-forward mechanism in our use case. However, this fast forward occurs at the same rate for everyone sharing the same animation stream. So it looks like they are all moving a little faster than usual to perform the new reaction, but they are moving through the animations at the same speed.
Reviewer 2 Report
This is a readable, detailed paper describing a useful addition to making crowd modeling more realistic and efficient. The authors do a nice job providing a background for and justification to their work. The only part of an evaluation that is not provided is a kind of gamer experience. That is, is there a difference in how noticeable or helpful the changes are to background characters, especially those toward the foreground, between the current state of the art and the authors' new methods? These kind of findings would make the argument even stronger, and would help game designers prioritize their approach.
Note that for this reviewer, the Dropbox link to supplemental footage did not work.
Author Response
Related to the suggestion, we updated the Conclusion, more precisely the penultimate paragraph from the "Conclusion and Future work" section.
Round 2
Reviewer 1 Report
Some of my English style suggestions were not taken, so I marked them again, and tried to give some more detailed comments. This time I scanned only the pages that I actually marked.
In particular I would like to see your response to my long comments in the left margins of pages 2 and 10. If you still choose not to modify the paper, please upload a "response to reviewers" file that explains why not (or send it to the editor if there is no such upload mechanism). Thank you.
Comments for author File: Comments.pdf
Author Response
Regarding the comment on page 10 under "Note that the offset change rate per simulation frame is fixed for all agents, so it looks like they are all moving at a normal speed." I think there is some confusion here. We say that all agents in a stream move at exactly the same speed (that's what we call normal speed). A stream consists of a large group of agents. Between the streams there are of course different change rates/offsets, i.e. different speeds, but this is not a problem because each stream has its own animations, so it is normal to have different speeds.
Round 3
Reviewer 1 Report
Again I have scanned only the pages of the manuscript which I marked.
We still have a misunderstanding about the speed of the animation. I believe I understand your comment about the streams being different, but still believe that the statement "all agents in a stream move at exactly the same speed" is not true. My comments on page 10 apply to a single stream. I believe I have proved in those comments in the last two reviews that all agents in the stream will move at two velocities, a slower velocity v1 to increase Ag.offset up to Ag.targetOffset (unless Ag.targetOffset is zero), and a faster "normal" velocity v2 after Ag.targetOffset is achieved. It is true that v1 and v2 do not differ between agents in the same stream, but since they are not equal, it is not true that all agents move at their "normal" velocities all the time.
Comments for author File: Comments.pdf
Author Response
Related to the statement "all agents in a stream move at exactly the same speed", you are right, when transitioning to a new animation, the agents sharing the same animation stream could actually have different speed rates. It looked like they were still moving at the same speed, since the difference in the target offsets was not that big and was slowly changing linearly in time, as you write in your first comment.
Also, I did the suggested line, it was a bug, thank you very much for your suggestion. I can not wait to put this change into practice too!
Many thanks!
Round 4
Reviewer 1 Report
Thank you for making all my suggested changes.
This manuscript is a resubmission of an earlier submission. The following is a list of the peer review reports and author responses from that submission.
Round 1
Reviewer 1 Report
Animation in massive crowds creates a lot of performance problems when designing virtual environment applications in smart city, security, entertainment, and education. Therefore, the manuscript rightly considers improving the performance, variety, and usability of crowd animation systems using the GPU. A proposed approach requires no additional memory other than the source and target animation streams. Besides, it increases the number of agents that can simultaneously transition from one state to another. A time dilation offset and splitting agents into parts is especially useful.
There are also some minor problems in the work that should be corrected before publishing the paper, as below.
- Figure 1 is unreadable (too dark).
- Line 147: v and n should be written in italics;
- Formula (1): a citation is needed;
- Line 236: Both PA and Pa (Eq. 2) are used. Are they the same variables? If so, the way of recording should be standardized.
- Line 431: What is alpha?
- It is not clear what is the efficiency gain of the proposed method in relation to classical methods?
Correcting the above shortcomings will likely make the article more consistent.
Author Response
We attached changes made to the manuscript.
Author Response File: 
Author Response.docx
Reviewer 2 Report
The authors present a timely and interesting research which can be used for multiple purposes.
The title of the paper should not be all capital letters.
The language used in the article is fine, only a minor spellcheck is required.
More references (which strengthen the scientific background) should be added to the article. The references also require some formatting as well: when citing journal articles, abbreviated journal names should be used.
In the introductory section the authors mention a few video games, phobia treatment applications, evacuation simulations that use this technology. The reviewer is interested in the types of crowd simulation techniques that these types of applications use. FIFA 22 is used as an example in this paper. Could this technique be used in the other applications as well? The authors should elaborate on this.
Author Response
We attached changes made to the manuscript.
Author Response File: Author Response.docx
