Crowd Simulation outputing bego files

[Borkowski]

Hi everyone,

I'm a student new to houdini,
First of all I really appreciate this forum, I want to thank everyone who posted hip files in this character section… it helped me learn a lot about chops.
I've been working on a crowd simulation for the last few weeks: about 70 people sitting on bleachers and cheering as if at football game. I'm looking for suggestions on how to make it more procedural. Let me explain what I've done so far:
I rigged a character with no IK and then animated a few different motions (jumping, standing, cheering, clapping, etc) then fetched out all the bone rotations to CHOPS and used some cycles, shifts, stretch and sequence CHOPS to make a few different reactions that all start at frame 1. I then used two different switch CHOPS (one for legs and spine and one for arms) to switch up the poses and output 7 different reactions as a series of bego files.
I assigned these to different points on a grid and use a random statement on the opdigits of each file SOP to offset when each reaction starts.
So I end up with just 7 different reactions for 70 characters but none are in sync.
But.... I feel like my chops are kind of wasted. I can go back and tweak them but I always have to output begos again. The only way I can think to get more subtle differences in the reaction is to copy the skeleton multiple times but I figure that would be too memory intensive. Are there more ways to alter the bego files besides just offsetting when the animation starts?
Any suggestions or thoughts on this, or any other methods for crowd simulation would be appreciated.
I'm new to this so if it doesn't make sense let me know. I can send my hip file out upon request if any one wants to take a look.

Thanks,

Ben Borkowski

[edward]

Are your CHOPs general enough to generate a large number of random sequences of motion? If you could, then maybe one way to get more variation is to base your CHOPs network on a random seed that is based on the output of the time() expression function. Then set up a script which in a loop, outputs a .bgeo sequence, change the random seed, output another sequence, change the random seed, output another sequence .... basically 70 sequences. This has been just mainly thinking out loud ...

[AdamJ]

I've been trying a similar thing myself and also hit a CHOP 'wall' heh. So far I've setup a single character (bird in my case), animated the rig with CHOPs and write out a slow motion version of the cycles. I've setup a particle network to give me the general movement, then I read in the cycle using a copy stamped 'speed' variable in my file sop to control how fast the birds flap depending on particle speed. (the file sop basicly skips frames to speed up the cylces ie. that why I have the slowmo cycles in the first place). But... like you I'm still thinking that the bgeo sequence way of doing things is not the most optimal. Idealy I'd like to have one CHOP network returning different cycle speeds to the copied geometry based on particle speed. Will let you know if any of my attempts are successful. If anyone has any other suggestions I'd also love to hear them..

Cheers,
Adam

[anakin78z]

Just thinking out loud here, and I don't think any of this is immediately applicable...

You don't want to make 70 copies of a skeleton because of memory, and more likely because it'd be a bitch to handle 70*number of bones objects. What if we had sop level skeletons? Say you could have an arbitrary number of character skeletons in a sop, and the chop could handle them all at once, instead of having 70 chops. the whole thing seems even more appealing when you're dealing with 7000 characters, and it'd be cool to be able to dial up and down the number of characters in that sop. I was thinking you could set up your character once, then make as many copies as you want. Since you have your chops and bones handeling all your deformations, you may be able to do things you couldn't do before, such as turning a characters foot as he turns to avoid an obstacle.

hmn... but cooking 7000 characters deforming in one sop is probably no good.

So then I'm thinking, what about that nifty new feature where you can call hscript from vmantra? What if we 'instance' 7000 characters, but the characters actually get deformed at rendertime. That seems more reasonable (I think), and is something you could try right out of the box.

Another idea, if you're not dealing with too many characters, is to whip up a nifty OTL with callback scripts to create characters at will, actually creating the skeletons and chops and whatever else you need.

Anyhoo, just thinking out loud... back to work now