kleer001

Looks cool. What problem does it solve?

Simple particle rules + time = life ?!

At my lovely studio we have a bit of an unfinished Houdini render pipeline. We're able to use the farm to bake out geometry, but only serially. Also, writing out the IFDs is serial. We only have a handful of engine licenses. This is painless for sims, but this is a problem with SOP geo renders that can be baked out in parallel. Mantra renders, however, work in full parallel glory. How can I put an "opparm -c /path/to/ROPoutputdriver execute" script call (or any such code) somewhere where it will execute IN the IFD as it's rendering, but not during IFD generation? I tried putting that code in the Mantra's (set to render nothing) Pre-frame/Post-frame script parameter, but those execute AT IFD generation (which is serial), which doesn't help. Would a Python SOP work? If so how would I trigger it on frame render?

What have you tried already? Where are you hitting walls?

It's impossible to help you without a hip file. Please upload one so we can see the broader context of your setup. "Center line" is ambiguous. Please provide demonstration geometry and a rough-in geo of what you expect to see.

Can't work with this personally, but can give some helpful time saving advice... get yourself a storyboard with a timing sound track. Maybe start with miming what you want to happen with your hands or some props or drawn on paper in front of a camera. Then edit the beats to what you like. This will save you tons of time and money and frustration. Buy maybe you already know this. I have no way of telling. If you do, then please ignore me.

Those aren't grains. We're looking at geometry constrained to the grains. It's basically Vellum Cloth. If you want hard little spheres start from points, not geometry. Here's a quick intro to grains to illustrate the actual operative piece of geometry:

If you have $9000 to spend on a rig you're better off buying a box for Linux. Waaay more bang for your buck. If you buy all the components from the same store they can usually put it together for you. This was my rig I put together last year for $4000 and it's screamingly fast. https://pcpartpicker.com/list/4hGHsZ Also consider rendering with Redshift.

Because you have a bunch of overlapping grains and there's no other way to resolve them. Use a polygon sphere instead of a mesh, and redefine your grain sizes so they don't overlap. Vellum HATES overlapping points and will explode.

Close! The winner is https://rsnapshot.org/ I finally remembered that the backup directories are ".snapshot" not ".backup" And yes, a cron job 100%

Hahaha, yea, that's probably how it was implemented. That's how almost any regular function happens. But sadly that doesn't help with my question.

While at a couple different studios (DD, FrameStore, DNeg) I think I correctly recall that they had a system setup on Linux where your smaller files (not caches) would be saved to daily in a ".backup" folder next to the folder being backed up /usr/kleer/docs would be regularly backed up in (I think) /usr/kleer/.backup/docs And is was like that for lots of directories. Or something like that. I can't exactly remember. And the search terms are so vague I can't find what this particular backup workflow is called. I can't even recall if they're on a separate disk or on the same disk as the original path. This was really useful when trying to recover a mis-saved file or some other snafu and I'd love to implement it on my home machine, but what the freak is it?!

Control is an illusion. Unless of course you created this tool for a client. Then, technically, it's not yours.