Is it possible to calculate a DOP network using more than one computer? Like a render farm, but for dynamics.

this is a nice question.. i`m not have enough time for experiments, but very interested about mosix cluster project.

http://www.mosix.org/ [mosix.org]

this cluster grid make possible multicomputer calculations for most programs. I`m stick on patched kernel hangs, and can`t find workaround..

This interesting question. May be somebody find another cluster engine.

Thanks, that looks pretty good for what I need. And after a bit of searching, it's the only one I've found that can be installed on Windows.

heydabop
Thanks, that looks pretty good for what I need. And after a bit of searching, it's the only one I've found that can be installed on Windows.

Unfortunately there is no such a cluster software which can take your non-threaded application or algorithm and spread it around for a whole bunch of nodes automagicaly. Most of these systems, and there are quite a few of them, manage load balancing in cases there are dozens of simultaneous processes hungry for resources.

Unless Houdini won't divide its simulations into separated processes, any cluster won't help.

Saying that, muli-processing/ mulit-threading is a holy grail on computational physics, SESI knows that, like any other in that game, and most probably strikes to make it happen one day.


cheers,
skk.

SYmek

heydabop
Thanks, that looks pretty good for what I need. And after a bit of searching, it's the only one I've found that can be installed on Windows.

Unfortunately there is no such a cluster software which can take your non-threaded application or algorithm and spread it around for a whole bunch of nodes automagicaly. Most of these systems, and there are quite a few of them, manage load balancing in cases there are dozens of simultaneous processes hungry for resources.

Unless Houdini won't divide its simulations into separated processes, any cluster won't help.

Saying that, muli-processing/ mulit-threading is a holy grail on computational physics, SESI knows that, like any other in that game, and most probably strikes to make it happen one day.


cheers,
skk.

Dang….okay, thanks for the information. But, if you have a dual-core, or quad-core computer, won't DOP's use all those cores?

heydabop
Dang….okay, thanks for the information. But, if you have a dual-core, or quad-core computer, won't DOP's use all those cores?

DOPs are complicated system of micro-solvers, They were build in flexibility in mind. You can literally arrange your own solvers in it. So there isn't easy answer for that questions. Moreover SESI tweaks it quite often, turning on and off some features and optimizations. Yes, dops are multi-threaded and can use your cores (8 in my case), but not like you would expect based on Mantra example.

This is far more complicated issue. For example, collision detection for cloths may be multi-threaded, but it's just 30% or whole computation, and the rest is not (for example, I don't know that!).

In general Dops are not a demon of speed in a current stage, but they are definitely most robust dynamic environment you can buy.

cheers,
skk.

Okay.

if dops uses multi cores i can't see it on my setup…
i have a quad core with 4gb ram in xp64. the task manager shows 25% cpu usage when im cooking an rbd sim in dops. am i really stuck with just one core?

AFAIK some parts, but not all, of DOPs can only use one core.

so if i can do a fractured object only with one core, how would a big studio achieve large scale fracture effects?

Distributed simulation farm.

but from this situation it would appear you cannot distribute this kind of simulation

Just because your computer says it's using 25% of your max cpus doesn't mean it's using 1 core. While I'm running pyro sims I routinely have either top or xosview open in a shell to check core usage. Usually there is 1 main thread that is stuck at 100%, while others routinely spike upwards of 30-45%. For upres sims it can easily use 100% of cpu power, like mantra.

In the studio I work at, we use Qube for distributing renders, sims, and caches across our render farm. SOP caches (including POP sims) can be easily distributed since they're based on seeds most of the time, so you can expect everything to line up. DOPs already contains the necessary nodes for distributing both volume fluids and liquid simulations, but we had to add some additional scripts to get them working with Qube. Rigid Sims are a special case, since there doesn't seem to be an easy way of distributing collsion calculations. I'm sure larger studios have ways of doing this.

queglay
so if i can do a fractured object only with one core, how would a big studio achieve large scale fracture effects?

Like everything in large-scale production, the problem is broken down into manageable and directable subsections. Just chopping up tons of geometry and throwing it into a simulation is production suicide

Usually certain parts of a hero destruction sequence are keyframe animated so that certain “beats” are hit, visually speaking. This is all painstaking previsualized, blocked and animated. Often times some reference footage or temp simple proxy simulations are run to provide cues for true ballistic trajectories and such, and then these keyframed pieces serve as “inactive” RBD objects.

If two collapsing structures don't interact (in a visible way) then these are separated into two simulations. Small debris is a run “on top of” RBD sims of large pieces. The same with particle dust, sparks, etc.

Even with this, lower-resolution proxy geometry are used for the collision geometry and them more highly detailed geometry substituted.

Another way to “distribute” simulations is to run several variations of simulations on the farm simultaneously, varying forces, substeps, constraints, anything that can be varied. This gives you a fairly good idea of what works technically and visually the next day.

For RBD sims in Houdini, some phases of the (quite lengthy) preparations are multithreaded, but neither the RBD Solver nor ODE Solver are multithreaded/distributable during the solve.

The same tactic above is true for fluid effects, but some fluid effects can be easily distributed on multiple cores and machines.