From the looks of it, cache/memory settings (for sops at least), isn't saved with the hip file. (sopcache)

Is there a compelling reason why these settings shouldn't be saved in the hip file?

Say you are working on two hip files. One is light and fluffy and the other is huge and heavy. The huge hip file has aggressive memory unloading going on, but then you go to the light hip file and while working set the unloading to never.

After lunch you come back to work on the big hip file again, and it crashes whenever you open it due to memory. (houdini -n to the rescue)

Anyway should these options be saved in the hip file?

Yes? No? Martini?

What about unload flags?

edward
What about unload flags?

Exactly. Depending on my preferences file in my $HOME directory, (or someone else if I'm passing around hip files.)

If their preference is never unload sops regardless of flag (sopcache -U never) and they open up the hip file boom….memory crash.

There are pros and cons to each…does the hip file override user preferences or does the user preferences override the hip file. Personally I think having the hip file trump the preferences is better because it places the responsibility of memory management in the hip builder's hands and not who ever happens to pick up the hip file next.

The user preferences must override unload flags because otherwise, there would be no global control. If I'm using an 8 GB machine, I don't want to globally hunt for unload flags to turn off.

What I was suggesting is that if you're designing an asset say, only the asset creator knows how to properly control the unload flags. The user of the asset is the one that knows his machine limits. So I don't really see .hip files containing the sopcache preferences.

But there is global control. If the global preferences (like SOP Cull Level 3) is saved to the hip file and the user with “teh ubar” computer wants to turn off unloading, then they can open up the global preferences, set the SOP Cull Level to 0 and save the hip file.

$HOME/houdinix.x/houdini.pref should specify the default sopcache values


sopcache.level.val := 0;
sopcache.memorylimit.val := 1024;
sopcache.unload.val := “Never”;
sopcache.memory.val := “Never”;
objcache.memorylimit.val := 51200;
objcache.memory.val := “Always”;


Once the hip file is saved though those settings should travel with the hip.

Besides, hscript doesn't even look at houdini.pref's cache settings.

What if instead of using unload flags, I just set “Cull by Memory” to 512MB, (crappy machine), then sent my hip file to the farm to be rendered via hscript. Since hscript ignores the settings its gets set to the default sopcache -M never -U flag -m 1024
which may or may not be what you want. So now you have to add a Pre-Include script that sets it to
sopcache -M always -U flag -m 512

In your example though, now the uber user needs to do this for *every* hip file that is loaded. Similarly, there will be pain for the non-uber user opening hip files saved by the uber user. I'm not saying that's a valid scenario but it's a scenario anyhow. If one is on the farm, then the farm should control this, not the hip file (456.cmd?)

That's it….we need to fork Houdini.




Seriously though, there are pros and cons and workarounds for both ways….although I do agree that being user-centric, (not hip), is better.

You have won this round Edward……until we meet again.


(JC got tired of me whining so he just bought me one of those Quad-dual core machines.) :wink:

Generally I believe that cache size settings should be global preferences, not per-hip file settings. Why? Because your installed memory doesn't change between sessions, and this is the main factor in setting cache sizes. The hip file is more likely to be used on various machines, and if you happened to switch between a 4Gb 64bit machine and a 1Gb farm machine, you'd be in trouble.

Nice… 4 CPUs. You do realize that JC will expect you to work 4x as hard to keep 'em running now… right? :shock:

For the record, I told him a quad dual system, but instead just got this:

http://www.hyperfocaldesign.com/reviews/hdri-book-review.html [hyperfocaldesign.com]


which looks interesting. The Lamborghini was right out.

Cheers,

J.C.