crowd sliding

   3697   3   1
User Avatar
Member
21 posts
Joined: April 2006
Offline
Is there a way to lock footfalls of the agents so they don't seem like they are sliding? Most other crowd packages have a way to deal with this, and I feel it is pretty crucial to getting a convincing crowd. Perhaps it can be similar to the agent projection and terrain adaptation, which is a pretty deep python or hscript file.

I also find it quite difficult to blend between actions and combining that with retiming of the mocap clips. Sometimes you tweak the particle speed, or else you adjust the in-place gate speed.

There is a lot of potential for crowd system, but to be considered, it really should be a better, faster, easier solution, not just different but equally difficult.

thanks
Josh
User Avatar
Member
2529 posts
Joined: June 2008
Offline
So have you removed forward motion from your agents during the bake process?

If so, play around with the In Place Gate speed of the walk state node inside the crowd_sim network. This is used to compensate for sliding.

If you have not removed forward motion from your agents, you need to. The entire crowd system assumes your agents are “in-place” animated.
Using Houdini Indie 20.0
Ubuntu 64GB Ryzen 16 core.
nVidia 3050RTX 8BG RAM.
User Avatar
Member
21 posts
Joined: April 2006
Offline
Thanks for the reply…

So the mocap data I am using is moving through space, so not walking in place.
The reason for this is because I am trying to push the capabilities of the crowd sys a little. I did remove that offset during the process of baking clips out.

The task was to make a group of agents go from idle, to walking, then after a few cycles, go back to idle. It failed pretty hard.

The blending of clips is painful, and difficult to dial in. Going from a standstill to walk usually requires an in-between clip (idle_to_walk) in massive, for example. Following that idea, it was impossible to get a smooth transition that didn't slide. The agent is basically controlled by particle forces, not necessarily the inherent motion from the mocap (although that is one option). In fact, the only way I was able to get a decent look was to use the ‘lock particle speed to mocap’ setting on the crowd solver.

So that is one problem, getting the agent to match speed on anything other than a single walk cycle.

The other problem is actually controlling the feet placement, after the gross motion of the agent is set. Even with just a walk cycle, the feet slide ever so slightly. One foot will slide forward a bit, another foot will slip backwards.

It also seems like there is some slight blending even between the same walk cycle, which causes a slight pop, which may be the cause of the sliding.

I guess the real question is if there is anyone who has been successful in setting up a crowd on their own with more complex clip blending.

thanks
Josh
User Avatar
Member
2529 posts
Joined: June 2008
Offline
The task was to make a group of agents go from idle, to walking, then after a few cycles, go back to idle.
I am currently working on the same thing.

I have not had any clip blending problems however, I am not using mocap, I am using hand animated FBX rigs. Do your mocap rigs both have the same skeletal structure? My two agents do have identical rigs and the motion from idle to walk is fairly smooth. It could use some easing control. But my motion is from standing to a ground kind of four legged walk. The rig bends over based upon the number in the transition node. When it comes out of the walk and stands back up into idle the timing value in the other transition node is used. I assume this all done in a pose-to-pose manner.

As far as sliding goes I have encountered cases where an agent will stop it's walk cycle and just slide, then transition to idle. I think I found a fix for that. In the Crowd Solver, under Animation Behavior using Method Retime Mocap To Particle Speed change Allowed Variance from 100% to 50%. In my situation this eliminated those occasional cases where the walk cycle would stop before the particle motion was finished. What is probably going on is that the random number generator is choosing some number near 100% as a start point in the walk animation and it reaches the end before it should. By limiting the solver to only the first 50% as start points it has cleared that issue up in my sim.
Using Houdini Indie 20.0
Ubuntu 64GB Ryzen 16 core.
nVidia 3050RTX 8BG RAM.
  • Quick Links