Jump to content
tuncay

Dops Slow?

Recommended Posts

Is it because I am new to houdini thus doesn't know the tricks yet or is the houdini dynamics system really slow? (Comparing to maya).

Share this post


Link to post
Share on other sites
Is it because I am new to houdini thus doesn't know the tricks yet or is the houdini dynamics system really slow? (Comparing to maya).

It seems to me that in default settings it's much more precise then Maya dynamic system. Yet it's very scalable so you can manage your setting to work on very complicated scenes. It can be much faster with some cheap settings. There are also many tricks to aid in performance issues. Please, note also, that Houdini interface interaction is generally speaking quite slower then other app's GUI.

Share this post


Link to post
Share on other sites

Thanks for the reply SYmek. I think as you said Houdini default settings are a bit high. And I made the comparament in terms of the defaults.

About the interface. I think the houdini interface is not slower than other apps. There are slow part for example if there is a floating panel the interface may get real slow. Its use of overlay planes have some limitations about this I think. But generally its interface seemed really fast to me. ( with a fireGL T2 ) In maya working with hypershade for example is a pain. But Houdini shader related interfaces are as fast as other parts of Houdini.

Share this post


Link to post
Share on other sites

When you say DOPs, do you mean the RBD Solver in particular? If so, you'll find that the RBD Solver is very efficient for highly detailed models, due to the (default) Volume representation. While its not terribly fast at simulating a brick wall, pour 2000 detailed Ford Cobras into a box and it'll surprise you. Also, are you on 8.1? If so, there a couple of speed increases to the regular polygon/polygon collision (Thin Plate) stuff I believe, along with the RDB AutoFreeze DOP too.

About the interface. I think the houdini interface is not slower than other apps. There are slow part for example if there is a floating panel the interface may get real slow. Its use of overlay planes have some limitations about this I think. But generally its interface seemed really fast to me. ( with a fireGL T2 ) In maya working with hypershade for example is a pain. But Houdini shader related interfaces are as fast as other parts of Houdini.

Yeah, on pro-level cards the floating windows don't have a performance impact. On some mid-level consumer cards you'll find this does happen all too often, I'm afraid. Strangely enough this has been the way of Houdini since its inception and I'm kinda surprised SESI haven't found a more generic, more widely compatable technique of drawing some their UI components.

Cheers,

Jason

Share this post


Link to post
Share on other sites

Also writing you .sim files out to disk seems to help alot. But they can be really big files. And make sure you start at frame 1 not 0...or you will be wondering what the hell is going on :).

Share this post


Link to post
Share on other sites
Also writing you .sim files out to disk seems to help alot. But they can be really big files. And make sure you start at frame 1 not 0...or you will be wondering what the hell is going on :).

Also, if you weren't aware, you can write .sim.gz extension files if they too unweildy. This will (un)gzip them on the fly.

Cheers,

Jason

PS. There are a lot of file formats in Houdini to which you can add the .gz extension. BGEO is one of them - and historically so was .pic and .hip.

Share this post


Link to post
Share on other sites
Also, if you weren't aware, you can write .sim.gz extension files if they too unweildy. This will (un)gzip them on the fly.

Cheers,

Jason

PS. There are a lot of file formats in Houdini to which you can add the .gz extension. BGEO is one of them - and historically so was .pic and .hip.

Great peice of info...Thanks Jason! :)

Share this post


Link to post
Share on other sites

Actually, all .sim files are gzipped all the time. Technically, they are gzipped in a piecewise fashion, rather than the whole file being gzipped as a unit, but that doesn't make much difference. Just try running a .sim file through gzip to compress it. In a very very simple test scene, the size went from 11209 for baked0001.sim to 11018 after "gzip -9 baked0001.sim". So .sim is actually a pretty efficient file format. The problem is that the _entire simulation state_ is stored in each file. This is necessary so that any .sim file can be loaded into an otherwise empty Houdini session and you'll get something sensible. This obviously results in a lot of duplication of saved data.

Fortunately when you load in a sequence of files, Houdini actually knows when a piece of data in one file is the same as a piece of data in another file. So if it tries to load a piece of data that is already in memory (loaded from an earlier .sim file in a sequence), it skips right over it. So when loading a sequence of .sim files for an RBD simulation, the SDF data and geometry data for your RBD objects are not being reloaded each frame (even though it is all stored in every .sim file). Only the stuff that changes over time gets loaded on each frame.

Just an interesting tidbit about .sim files...

Mark

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×