dop - very slow reading sim file.

   13705   14   2
User Avatar
Member
122 posts
Joined: May 2006
Offline
Hi, i made a fracture obj, not too complex, it's a box, shattered about 600 pieces. Then i save the simulation to .sim sequence using file node. After finishing the baking process. i restart houdini then re open the scene file.

Something wierd when i tried to read from the sim file. The process is really slow and in the status bar , it tells me something like :…. dop network cook. It's too slow as if houdini is cooking back the simulation.
why it re-cook the simulation? i only want to read from .sim file that has been cooked/baked. I tried to disconnect that file node and also delete the whole original simulation tree and let the ‘file’ node alone but still got no change, also i still got msg : … dop network cook.

I can get my simulation back, after a while, but i'm confused … why it re-cook the simulation in fact i'm reading the .sim . I got BUG or what ?

thanx
User Avatar
Member
2624 posts
Joined: Aug. 2006
Offline
I can get my simulation back, after a while, but i'm confused … why it re-cook the simulation in fact i'm reading the .sim . I got BUG or what ?

If you save your scene with a node set to display that is the output of your simulation of course when you re-open the nodes will re-cook. Likewise if you write your sim out to disk then set the input node to display, your files will be read from disk without the recook.

Rob
Gone fishing
User Avatar
Member
122 posts
Joined: May 2006
Offline
circusmonkey
I can get my simulation back, after a while, but i'm confused … why it re-cook the simulation in fact i'm reading the .sim . I got BUG or what ?

If you save your scene with a node set to display that is the output of your simulation of course when you re-open the nodes will re-cook. Likewise if you write your sim out to disk then set the input node to display, your files will be read from disk without the recook.

Rob

Sorry, i don't get it, ok let's forget about recook, now i'm concern about the speed
here's i made it simple. After i create a simulation and save the sim to disk, i deleted ALL the nodes, delete everything !!! i just leave my ‘autodopnetwork’ alone. Inside this node , i also delete everything! i only keep one node which is the ‘file’ node. this is the node i used before to save the simulation.

Now i change the mode of my ‘file’ node to ‘read’. So i'm READING back the sim from disk. The problem is : The time is needed to load/read the sim doesn't make any sense. It takes almost as long as when i first time calculating the sim, i also got msg : ‘dop network cook’ in status bar. In general , reading back the baked simualtion should be faster than re-calculating the sim, That's why in my case, i didn't find any benefit of baking the sim. Don't you think?

thanx
User Avatar
Member
2624 posts
Joined: Aug. 2006
Offline
Clearly you are not doing this correctly for starters why on earth you are you changing file nodes from write to read ?. If you use the shelf tools to set up your dops sim it does everything for you.

Post up a scene file

Rob
Gone fishing
User Avatar
Member
861 posts
Joined: Oct. 2008
Online
I don't often write out sims in the dopnet (I know I should) but unless my memory is failing me I think it reads every frame until the current frame . So, it spends time preloading stuff. Could that be a factor?

Not sure that's completely right.

Also, try disabling the sim (bottom right button). Does it show the sim now? If not, something isn't set up properly.
--
Jobless
User Avatar
Member
665 posts
Joined: July 2005
Offline
I've had the same slow behavior.

Also, maybe turning on the ‘Timeless’ Button on the sim might help?

It's been a while since I've investigated, but long ago, I just started writing everything in SOPs….

Good luck!
-j
User Avatar
Staff
2540 posts
Joined: July 2005
Offline
The main reason to write out .sim files is if you are concerned that your simulation will fall over for various reasons: memory, distributed sims with farm machine that goes awol, etc.

What you can do in this case is at the top level DOP Network node, enable the “Explicit Cache” option. Modify the Explicit Cache Files parameter to suit your needs and leave the Explicit Frames to Keep at 0. This should improve the performance of reading the cache files from disk.
If your simulation does fall over on a frame, you can restart on the previous frame with this option enabled and if a cache frame exists on disk, it will be used and if not, it will have to re-simulate which is exactly the scenario you have with a failed sim.

If you aren't concerned about your simulation failing, then cache your results out of SOPs as was mentioned previously.
Most times on large sims I go directly to SOPs and write out the sim to disk then load in the geometry files off disk to see the result. bgeo's tend to be much smaller than .sim files too.
There's at least one school like the old school!
User Avatar
Member
122 posts
Joined: May 2006
Offline
circusmonkey
Clearly you are not doing this correctly for starters why on earth you are you changing file nodes from write to read ?. If you use the shelf tools to set up your dops sim it does everything for you.

Post up a scene file

Rob

Hi, ussually i use ‘automatic’ mode, but since i'm trying to dig the problem, so i did some test with ‘read’ and ‘write’.

Anyway i've just find out that i need to cycle the simulation once from the disk (.sim) then next loop , i got normal speed. So maybe i have wrong intepretation of ‘reading’ sim from disk. I thougt it's similar to reading .mdd (just for comparison) where u can load the data and play it back straight from disk without any time needed to re-compute the simulation. Logically The simulation has been written to disk, so when you load it back from disk , then my question will be : does it need to re-compute the simulation?

thanx
User Avatar
Member
122 posts
Joined: May 2006
Offline
Soothsayer
I don't often write out sims in the dopnet (I know I should) but unless my memory is failing me I think it reads every frame until the current frame . So, it spends time preloading stuff. Could that be a factor?
.

Yes i think that's the factor , i've just run through the simulation once and then next looping is ok. It takes some time to preload. The problem is : the time is needed to preload is too slow … as if it's re-calculating the simulation instead of preloading. I can load .mdd and can play it back directly and preloading is much much faster, i know they're different but the point is the logical workflow of both seems to be similar.

thanx
User Avatar
Member
122 posts
Joined: May 2006
Offline
jeff
The main reason to write out .sim files is if you are concerned that your simulation will fall over for various reasons: memory, distributed sims with farm machine that goes awol, etc.

What you can do in this case is at the top level DOP Network node, enable the “Explicit Cache” option. Modify the Explicit Cache Files parameter to suit your needs and leave the Explicit Frames to Keep at 0. This should improve the performance of reading the cache files from disk.
If your simulation does fall over on a frame, you can restart on the previous frame with this option enabled and if a cache frame exists on disk, it will be used and if not, it will have to re-simulate which is exactly the scenario you have with a failed sim.

If you aren't concerned about your simulation failing, then cache your results out of SOPs as was mentioned previously.
Most times on large sims I go directly to SOPs and write out the sim to disk then load in the geometry files off disk to see the result. bgeo's tend to be much smaller than .sim files too.

the main reason why i write .sim, is simply when i re-open the file next time, i don't want to spend more time just to re-calculate the same simulation again. It's been done once and i want to save it, so i can load any time. am i doing it wrong? i'll check the ‘explicit cache’ later and thanx about SOP idea.

thanx
User Avatar
Member
122 posts
Joined: May 2006
Offline
jacob clark
I've had the same slow behavior.

Also, maybe turning on the ‘Timeless’ Button on the sim might help?

It's been a while since I've investigated, but long ago, I just started writing everything in SOPs….

Good luck!
-j

Hi, use SOP means using obj sequence to store simulation output? That's a good point, i didn't think about it. I ussually use ROP out to .mdd . Thanx a lot.
User Avatar
Member
122 posts
Joined: May 2006
Offline
is it the ‘raw’ simulation which is stored inside .sim ? or baked point or geo like .obj/bgeo sequence or .mdd ? i open the file , it's binary… no idea.

thanx
User Avatar
Member
1390 posts
Joined: July 2005
Offline
metaclay
is it the ‘raw’ simulation which is stored inside .sim ? or baked point or geo like .obj/bgeo sequence or .mdd ? i open the file , it's binary… no idea.

thanx

*.sim files are states of simulation per frame with all data needed to proceed further in sim or add another objects. Pretty much everything.

I usually opt for storing just baked geometry also. Clean and fast.
User Avatar
Member
20 posts
Joined: July 2007
Offline
Hi all, I just want to extend this discussion because I am having the exact same problem, the above discussion seems suggest that you only need to save sim files for rare case.

I personally like to use the sim files because I usually need to query the sim data back to SOP context and it is very handy to have all the information in the files. But I constantly facing the slow sim data loading problem. As the OP said, the time need to load the sim data is just the same as re-simulate the whole simulation again. And I found it quite inconvenience.

The problem remain, if all the simulation data is saved in the sim files, why it take so long to go to a specify frame of the simulation?

I just think things could be better…
User Avatar
Member
3 posts
Joined: Jan. 2023
Offline
Hello. In my case, disconnecting just above the cache node and showing the node below the cache speeded it up by eliminating unnecessary cooks. It might also be a good idea to convert it to USD and read it in the context of the stage. It's simple, but I worked hard.

thanx
  • Quick Links