I am looking at recreating my nuke language versioning hack in flame.
In nuke I have the write node change the masterswitch node (like a mux) to switch between different input assets on write. this also works through deadline
Imagine 3 seperate languages inserts for screen replacements and 3 versions need to be rendered.
Has anyone done something like this in flame?
Yep,
I am doing that sometime to do versioning when the CG is different for different variants of the output.
Linked mux is useful. I keep the master one close to the render node and it controls the others ones at different part of my tree.
I will be easier to manage if MUX could have input node rather than the unclear multiple input and if the switch was a drop down (with input number - name of the input) rather than just a field to enter the input number ID.
I am missing the label field that you have in nuke to add comments or expressions. It makes the life easier for the next graphist that have to pickup your work.
F
If you could link on executing a render to the mux it would be the same. Sadly I don’t think there’s a way other than manually switching the mux before rendering the output. What I do is add a couple additional muxes linked to the same master mux such that if I try to render an output with the mux incorrectly set, an additional action node renders the text, “UPDATE MUX” in giant red letters over the whole picture.
Shit’s idiot proof.
How about a MUX offsetting the time by the frame range amount, just before the Switch MUX. Then adjust the starting frame in the Write node. That way you render all your inputs sequentially on after the other. You will have to triple your frame range tho.
Hacky!
Not a switch procedure, but you can also try doing a multilayer approach (ala Nuke). Comp your three languages and feed them to three layers in a action node. Split each layer into a separate output.
That works too but takes more nodes and is prone to manual problems. Easiest is all options in a single action node as separate outputs piped to separate render/writes.
Hahahaha exactly. Should have kept reading… @milanesa
I made a feature request for something like this about a year ago for this exact use-case: FI-02179.
I might have a stab with python, should be possible to change the mux value and then trigger a render similiar to what I can do in nuke hmm this is so useful to not have to manually
switch stuff
Here’s what I would try to do in Python:
1- Put your code in the batch_render_begin() hook in /opt/Autodesk/« version »/python
2- Have your code pop a Qt window asking for which input to use.
Your code could use the input_selection attribute of a MUX node to set the desired input.
Note that you would need to implement the same code in the batch_burn_begin and batch_export_begin hooks if you would like to have the same workflow in Burn and in the Write File node.
Also, it might be a much more complicated to make this work with the Render button instead of Render Range because you would need to deal with multiple Render/Write File nodes at once.
Did someone figure out a way to do that ??
I used batch versionings a lot and never got rid of removing the user to be in charge what should be exported. The semi automated version works (for me) good enough to not focus in fully automating scripts right now.
For example here an old batch render area, that does this. Instead of a script, 2 mux nodes do everything needed inside the whole script, to manage a lot of versions. And if the mux are setup wrong, the writenode will burnin an error, that sth was not wright and will tell you, wich mux is wrong.
its like factorio but in flame
Factorio is flame batch litetm
OMG, you guys need to request a Context Variables System for Flame soon.
It was part of my reverse users group request…
I used this setup. You have to be in a certain state of mind to use it let alone set it up…
An example of Graph Scope Variables in Nuke. Still in its infancy compared to Houdini and Gaffer, but a really nice addition.
I don’t use Flame enough o envision how it can be implemented, but IT is screaming for something like this…for all those deliverables you guys have to deal with.
Yep. That’s a great start. I need to check out the 16/15.2 beta… but I’ve been busy.
My first real aha with context variables was actually doing large-scale layout in Clarisse a decade or more back. SideFX borrowed aaaaaalot when implementing Karma and Solaris.
Shit slayed.
Its is still super buggy, but they have already implemented some suggestions. Hopefully a few more things get injected and ironed out before the next releases.
