this drives me bonkers!
voted!
This is not what I’m looking for (though I do like the idea of a write-node that can also pass through, a sort of more tangible cache system)–I want something that will be live-looping in a second viewer as I adjust paint and roto. this is the closest thing I can find to it in my present search, but it doesn’t appear to allow a 2-up view where you can adjust specific keyframes in one viewer as the other one loops live.
TWENTY TWO YEARS AGO there was a plugin (“Biped” maybe?) for 3ds Max that would make a stick-figure version of your character that would loop the whole animation live and realtime as you adjusted it. This way you could adjust keyframes and see the result live, without having to stop, cache, and hit play. Very handy.
If you were painting, rotoing or stabilizing a shot you’d be able to adjust small aspects and see the results live in a second window. It would allow you to to get impossible tracks done, to roto and paint without bubbling and to make better animations. A win all around.
2 Likes
Combustion did this! It was great! Almost great enough to get me using combustion! Alas I had my hands full learning flame.
2 Likes
As far as I recall (based on hazy recollections of emails with the mpeg group ten years ago) the mpeg standard specifies exacting standards for the coding aspect of the codec but allows software to differ in the decoding aspect of the codec. When I pointed out what nonesense this seemed to me with similar examples of colour difference the fella (a big shot at Microsoft) got quite angry at me and we progressed no further.
I tried to get all the bigwigs at the mill involved in the conversation but they didn’t seem too interested. I think that’s a shame but it’s probably a thankless task (see my nonesense quote above).
Hey @Josh_Laurence isn’t that what a rendered BFX clip is?
Hi @MLandon,
Well… sorta. The rendered BFX is a snapshot of the upstream flowgraph. But in my idea; The CacheNode I’m thinking of is a passthrough clip that executes a cache in the background or during idle time or on command. So that you can have a render of the upstream nodes always connected to the downstream work. But if you have to go back (that never happens, right?) and change the upstream work, making that change blows away the cached frames and you can choose to re-render again. It’s a way to pre-comp work that you know works upstream and speed up the downstream work.
I really like Tim’s suggestion of caching a mux node, because it’s close to the same idea. The difference is with a mux node, in order to populate the cache you need a render node and you need to execute a render.
1 Like
Yes, my addition of the render node is simply a fallback if the MUX becomes accidentally unrendered (what are the chances of that happening) since it takes no more time to render the node as it does to cache it. It is, however, not a necessity.
I resisted the createBFX option for a while, but finally succumbed when I realized I could grab the color management node attached to my neat denoize, createBFX, render in background, add a mux with two inputs and connect up the new clip and old clip so I can switch on the fly. It’s obviously a couple more steps but the ability to process in the BG while still working is worth it for me.
I do use the cached mux quite a bit in other instances but when I want to be sure… createBFX
I am familiar with the setting. I speak of the occasions where nodes seem to “mysteriously” become uncached. For instance, if you have a gmask feeding a node that is cached and you make a change to the stream that feeds the input of the gmask, you will lose the cache even though the actual output of the gmask node is unaffected. As for timewarps, they auto-cache if you play through them while viewing the output. Paint node does something similar. Personally I prefer to not have pre-renders, although I will use them if need be. I dislike having to go through a large batch and reconfigure them any time I make a revision upstream. I would prefer caching that worked better. Maybe a cache lock that could be applied to various nodes in groups or individually . . .
1 Like
@ytf: This is exactly my experience, but I’ve never spent the time to figure out what triggers Flame to dump the cache and have just treated that little orange button as unreliable. This insight is great, thank you. But I still feel the current caching scheme is opaque… but maybe someone in here has a rule list that explains the logic driving it?
1 Like
I’d like to see something like this too. Maybe a feature like background reactor / render like in the linux and lustre versions.
So I got busy yesterday, my Friday.
And voted up some feedback requests.
Some from the Discord and some from this thread.
I was actually on a mission to add my own. “Include Setup” in the write node should include all write nodes in the setup. Not just the one that is saving the script.
I tried lodging a bug report first but apparently this is expected/designed behaviour.
Then I was going to submit a feature request but it showed me someone (Sean R. smith) had a feature request that was exactly the same.
Awesome, I thought, except I can’t vote it up 
3 years ago - FI-01697 Write Node includes all Render/Write notes when Include Setup is enabled
Anyone know why I might not be able to vote this up? 3 years too long?