We’re doing more and more water shots these days. To get one iteration, in a basic shot, means:
-base liquid sim
-splash sim
-frost/VRay render
-Krakatoa render
-FumeFX sim
-FumeFX render
-Nuke slapcomp
plenty of times these multiply significantly with adding more secondary sims, Stoke passes, etc.
I want to automate this, so I can build, in a nodal environment hopefully, an automation system, where you can build a graph of naiad, max and nuke scenes, and send to Deadline.
Any guidance or ideas on how that could be approached, would be great!
As we’ve discussed on fb, writing tools for doing all this work is rather easy. Writing tools with sexy GUIs for user-friendly interaction is another whole level of difficulty.
Depending on many factors, you might want to take a look at Qt from Nokia (or whoever owns it these days) and PyQt for example.
I’d need to know more about your workflow in order to be able to suggest what to use or which way to go “in Max” since I don’t use many of the tools you mentioned.
I’ll probably make it command line first, but I’d target having GUI for it - for complexity, productivity and team accessibility reasons. Running from both inside and outside of Max are an option.
I am the last person to disagree with a node-based UI approach, but I wonder why you would need that.
In your case, the dependencies are quite obvious and would make the design of the system much easier if they were created and handled implicitly.
So you just open a UI where you add the components you want to a ListView or something (a TreeView if you want a hierarchy display), and just check/uncheck what you want to submit. Let the script handle the dependency definitions.
Once the jobs are in Deadline 6.2+, you will get the Node View of the dependencies for free (and it is Qt based )
A node-based view would only make sense if you intend to constantly rewire the dependencies to do things that are out of the ordinary. But since you cannot render a Krakatoa pass without having the Naiad sim, that dependency would never be different… You cannot render the VRay Fume pass without the FumeFX Sim etc, and the Slapcomp will have to depend on the image outputs of all other render passes, so that’s also pretty much set in stone.
If you still want to do a node-based UI, Helium is built in the Krakatoa and Stoke DLLs already, so it is waiting for you to put something together…
These are good points. I’ll start with a rudimentary UI, inside of Max, which would be easy. The scenes will be premade anyway, I’ll just need to submit the dependencies and deal with the versioning. Thanks guys! I’m sure I’ll be having questions later
)
