Search - User list
Full Version: Massive
Root » Houdini Lounge » Massive
the_squid
I'm looking into Massive for handling crowd sims but I keep thinking Houdini could be good for crowd work as well. Anybody out there have experience using Houdini to populate stadiums, city streets, etc? I know it's capable of some of the simpler crowd sims, like ambient motion, people standing around, etc. But I wonder if something like Massive could be built within Houdini to handle more complex behavior, blending between motion capture loops, handling large data sets, but also knowing when and where to use certain motion loops (based off particle attributes for example.) I wouldnt want to go as far as simulating battles, but it would be good to have a crowd that can go from ambient “standing around” to running down the street if necessary.
EigenAlex
I do believe that Houdini is actually quite capable of doing behavioral simulation. Unfortunately, you will have to do a lot of technical setup first… It won't be as easy as Massive… Massive is definitely impressive.

Caleb Howard (Hi Caleb! ) of Rhythm & Hues did some behavioral simulation in Houdini for one of the recent feature film. From what he told me, he did it completely in Houdini's VOP network. It's very directable too. Pretty cool.

-Alex
the_squid
That's very interesting. I'm looking into getting Houdini into our pipeline and we're pretty sure we're going to go for it. At the same time, we've been getting a lot of crowd sim projects to bid on, so now the emphasis has shifted from Houdini to Massive. I realize Houdini could be utilized for doing some pretty intense crowd sim stuff, but it would take an initial investment of time which on commercials we dont necessarely have.
JColdrick
I heard an anecdotal rumour that working with Massive is not like turning it on, plugging in a few parameters and boom - big honkin' crowd. Because it's first an in-house tool and secondly being sold, there's only so much energy that gets put into customer support and good GUI. This may well have changed with LOTR wrapped - but from what I heard it was like pulling teeth…again what you would expect from an in-house tool. I'm not talking what it's capable of - I'm talking what you have to go through to get what you want.

All rumour, all anecodotes, someone knowing otherwise please feel free to step in and contradict…

However, implementing crowd/flocking stuff in Houdini is very doable, but as mentioned you'd need to do all that theory work that really is the one thing someone can say Massive has definitely done. Certainly non-trivial.

Cheers,

J.C.
the_squid
Excellent advice. This is exactly why I'm posting the question, because it's very possible that we could do everything we'd want to do with Massive in Houdini instead, but of course it would take a long time to setup. If Massive truly is plug ‘n play (as it says it is with it’s new “ready to run agents”) it might be worth purchasing. But if it will take us 1-2 months to get it working in our pipeline, it might be worth it to just build it ourselves. There are advantages to both, obviously. I would be really interested to hear what somebody who's had experience with Massive has to say about their experience.
MatrixNAN
Hey Guys,

I will back up JC statements. When I was at last siggraph for the crowd sim course they presented massive and one of the things that struct me was that one of the guys that was working on LOTR with massive to get the ORCs to stand in formation for a really long distant shot took 2 days to create the rule set up. The characters were nothing more than practically dots on the screen and each ORC was 5 hundred thousand polys. It just did not make since and seemed to be a big waste. You could do the same with thing with a point based system in Houdini to generate your crowds in like 5 minutes painting them in where you want to by using points generated on the geometry and get great results. Also you would not need to use 500k polys for each character. You could get away with only a few hundred or use a LOD to switch down to a lower res object when the camera is too far away for anyone to care. Basically I would look at using houdini for longer distant crowd sim shots because the results won't look much different and you can set it up much faster than doing it in massive. However if you have a close up to mid range shots then you better use massive or develope your own Houdini Massive tool. But like you said, you don't have time to create your own Houdini massive tool based on your current production schedule. I think it is really important to have a dual point and AI solution so you can switch back and forth between the two to get good results fastest. You defantly want to use Houdini for your point based crowd sim and not be like ILM who had to write 20 scripts just to orient the particle then bake the crowd sim particle data and go through every line of code to delete a single charater which would result in a ghost interaction effect because you basically have precalculated actions of character particles interacting the deleted character. So then it is possible to have a character having an intense fight with the air. lol Maya does not seem to be a good idea for doing the particle crowd sim. If you use Houdini you can delete the character based on his particle ID number and boom you are ready to play it back. That is so much faster and easier. The bad and the ugly. If you decide to do your own crowd sim. Then you really need to have a good LOD system because you have to use Copies and not instances so LOD really matters in this. Bake your simulation when you get it the way you want because otherwise the calculations at render time will go through the roof.

Cheers,
Nate Nesler
MatrixNAN
Hey Again,

Another little something that might be of interest to you. In Houdini if you are doing a point based crowd sim don't use POP sliding to calculate the terrian traversion. Instead get the particles to follow the UVs of the surface. This will be much faster to bake calculate and your render time will be far far less.

Cheers,
Nate Nesler
craiglhoffman
I just did a 3D crowd in a stadium not too long ago. The characters were from Maya and were already animated/textured, etc. so I baked them out as .objs and then randomly placed them around a stadium using a Copy SOP and stamping.

There was a lot more to it than this with expressions to drive all the randomness in the stamping part of the COPY SOP, a special SHOP where I could vary textures, colors, etc. on every person and all the animation was offset randomly so there was no “mirroring” of animation in the scene.

The bulk of it was done in a day (but the final product took more like a week for the first shot and a day for subsequent shots) and my Maya colleagues could not believe how quickly I did a big random crowd. But using the COP SOP meant big memory issues when rendering. I had to render in several layers and the renders took a while on my one machine.

-Craig
MatrixNAN
Hey Craig,

Yeah I agree I had simular issues with the memory using the Copy Sop just like you said. lol The render time was a killer. I need to go back and create a strong level of detail system to save the rendertime big time and build it into the copy sop solution with randomness like you said. What renderer did you use. I tried Mantra and it was not optimized on the copy sop so the render time was horrible. I am curious how fast it would be in renderman or Mental Ray.

Cheers,
Nate Nesler
jason_iversen
If you set it up to use instancing, you probably will not run into this problem. A recent commercial we worked on had about 20-30 unique high-resolution flowers, instancing at least 50,000 times and mantra screamed through it a nd rendered the entire field in 11 mins a frame, under 400mb of RAM.
MatrixNAN
Hey Guys,

Yeah well the problem with instances is that you can not get individual character animation which you have to have for Crowd Sims. Instances are great for doing flowers, trees, etc but those objects are not doing armature deformable animation so it works in those cases. Your right the instances are sooooo much faster. I think I calculate the difference around 1000 times faster than the copy solution without optimization. You can get it lower than a 1000 times for copies if you do some work to create a smart system for doing the copies. If you don't your just asking for it. LOD on copies is going to be the biggest render time saver you can do. Instances are great for crowds of space ships and stuff like that and you can even change the shading in houdini across all of the instances to make them all look different and that is a really big time saver on your rendering but you can't do this for deformable objects like characters. So its a double edge sword and you have to be careful what edge you decide to cut with.

Cheers,
Nate Nesler
craiglhoffman
Exactly. Having varied character animation and tons of randomness in everything kind of negates instancing.

One of the main tricks is to use a particle system with unique ID's and delete points out of your camera frustum and all points except the layers/levels you want BEFORE Copying. You don't want to Copy first and then delete things afterward to get memory usage at render time down.

The stamping expressions for randomness should reference the $ID rather than $PT since the point numbers will change as you delete points, whereas $ID will remain constant for every point.

Still, I could only render around 250 or so fairly lo-res characters at a time and I have 2 GB of RAM… It took most of the render time to generate the IFD file from my big complex tree and minimal time to render.

-Craig
MatrixNAN
Hey Craig,

Are you going to be at Siggraph this year? I would like to meet up with you there and get together sometime during siggraph. I think we could have some interesting discussions.

Cheers,
Nate Nesler
aracid
hey all

what about creating an otl of ur character and instancing with hscript at ojb level, and pass all the variables into that otl?

I've done hectic tests with huge geom being instanced through this way.

any reason why u use stamping instead of wrinting the expressions onto the points through some vop, and then hscript instancing using these points?

all the best

aracid
craiglhoffman
Uhh… basically because I know how to do stamping, but not hscript instancing…

Strangely enough I did do an OTL of the character where I could interactively change the model, textures, etc. and go through all the random variations (mostly just to show off how cool Houdini is to the Maya crowd), but I wasn't aware that there was a way to instance an OTL… I still think this would take big compute time and tons of memory since there isn't just one thing in memory being referenced over and over. All the characters would be different, so I don't think you would save anything…

-Craig
MatrixNAN
Hey Guys,

For crowd simulations I would not Instance or Copy an OTL character creator that would be a memory nightmare. Instead you would want to have the OTL be setup with a scripted copy that also included all your different LOD models generate by the OTL kicked out to disk and then hashed for fast access. Your character scripted assigned to the different points would then have to do a vector distance formula from the camera to their position to determine which LOD model to use per frame. You would have to either have a seperate rig for each model or and a smart rig that can have presets saved that it read in as a file on the fly and reassign the rigging constraint to it. This would be alot of scripting but it would be what you would want to do because it would save you alot of time for quickly generating characters and seting up large crowd sims without massive memory management overhead. Bake everything that you can to save at rendertime. Optimization and flexible character generators and behavor systems is the name of the game when it comes to crowd sims.

Cheers,
Nate Nesler
the_squid
Hey guys,

I wanted to update this thread since we just had our very first Massive demo! The demo was done by Steven Regelous and went over exceedingly well with the artists and producers. The Massive demo covered all the technical bases while also providing some very cool imagery and real-time interractive examples of Massive technology. They satisfied the thirst of both TD's and Animators alike, and the producers liked what they saw immediately.

Massive is very, very cool. Everything I wanted to build into my Houdini crowd (test) system Massive already has, including things I was pretty sure I wouldnt be able to do in Houdini, like having a useable RBD solver at my disposal.

I won't go into any details about how Massive works but it is a very fresh way of approaching crowd simulations. I highly recommend setting up a demo and looking into it.
sascha
There is also Behavior from Softimage, which has also a RB solver. It's a very strong tool with a very good mr pipeline. We used it for a feature film and it worked very well.
aracid
hey all

yeah, we're running massive here and you dont need 2 months to set it up, with prebuilt agents, u can get something out in a couple of days (or less with good coffee) - however that is if u use prebuilt agents. with something like stadium guy, its almost like a drag and drop situation, with a couple of animated sliders to control the general motion of the agents, its also nice because u can actually see the agents in the gui, and not wait for point instancing at render time to visualise what ur agents are doing.
now obviously stamping gives u a visual update, but that wont really help when u trying to do 10000+ agents.

one can also very easily extend what massive prebuilt agents can do, it is another story if u intend on building ur own agents, although its not difficult and is really flexible and interactive, its a time consuming task, expecially if u want it to move around and interact with other agents, but it is easy.

as for the interface, its one of the simplest setups ive seen and for any one coming from houdini, its even easier. it uses a DSO to handle the agents geometry and blending between animations, so its silly how little ram it uses.

we come from XSI - behaviour and althought its good, its the difference between MEL and VOPS, especially when it comes to customizing the way agents “think”.
massive uses a fuzzy logic setup that is graphical and intuitive, although the disadvantage is - having to leave xsi and include massive into our pipeline, mental ray support is in the new massive.

the only bit of coding we're done so far is strip the file down so we can render the massive agents out of houdini using air, so our lights and cameras are in sync.

in terms of wether houdini can do what massive can do, definately, on job specific tasks, i have no doubt and have done crowds in houdini, but when it comes to an open ended system, i dont see why one would want to, when massive does such a good job FOR crowds and AI, i dont think its rbd solution is at all a rival to dops.

so i too recommend it, in the same way id recommend Zbrush for its strengths.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB