That doesn’t work with a sequence. Only current frame.
I have a Python solution for you. Set up a batch paint with all of the settings and presets that you like and then save the setup for the paint node. I can write you a Python script that will add a batch paint node and load that setup. I use it all the time.
Can’t you just save it in your user bin? I have one specifically set up for roto, although I would rather have the option of setting a default like we have for action.
Oh, totally, but then you miss out on the power trip of being able to add one, connected, with a hot key!
Hmmm, you can add nodes from the User bin using the Search widget now. That would be the equivalent without Python
I’ve done many, many “write-ons” with this method.
Works a treat.
Is this a crazy suggestion…what if in batch you could reveal back from a grabbed frame?
It’s not that crazy but there are many possible problems with this. The main problem is that right now Paint does not commit the strokes. If you remove the source of the Reveal the pixels are gone. So you can imagine scenarios where:
- a Batch Group is archived but the Grabbed References are not
- a Batch Group is wired but the Grabbed References are not
- the Grabbed Reference is deleted or overwritten without realizing it was used in Paint
Yup. I can appreciate all of that. And the architecture needed to make it work which is why I said it was a crazy idea but perhaps possible. In my mind.
Hi Fred. Yeah these were the problems I expected would exist with procedural paint trying to use reference frames. But personally, I would take these rare occurrences of archive functionality, etc, if it meant I could just paint reveal a frame. This need comes up waaay more often, every day, than just a possibility of an archive issue down the road.
Are you sure about this??? You are saying a user would be OK restoring an archive to make a modification but the resulting image from the archive would not be the same as what was archived? It’s a BIG no go on our side.
We agree that using a grabbed frame in Paint would be useful, but using the Grabbed References from the Player/Viewport (which I think is what John suggested) wouldn’t work. We would need a dedicated “Image Buffer” like in Desktop Paint for this to work.
I get that. What I’m saying from personal experience is that the functionality need comes up exponentially more often than the concern of an archive issue sometime in the future. So the need comes up every day, but the possible negative consequence for me never comes up. I haven’t had to bring a project back from an archive in years, but I need this functionality literally every day.
*”Want” not “need”.
If you could see one of my Batches with a paint node with 30 goofy slipped muxes, you might agree that that’s worse than the remote possibility of an archive compatibility sometime in a theoretical future.
has anyone figured out a way to leave visible evidence of frames painted on? in an ideal world the paint node would leave timeline markers on frames painted on but i’ll take anything
Not as visual as you would hope but you can have a idea of which frames were painted on by going to the Edit list and look at the Range column.
Pls do not break archiving in the name of making the Paint node work like it did in the 90s again.
My idea was to use the grabbed reference if it was uncompressed. It was just a thought but I imagine there would be quite a big if coding involved to replicate the steps needed to make the batch replicable. My preference is the sand as yours when it comes to prodecural replication of a restored archive. It is essential.
I have been in @GPM ’s situation with a chain of paint nodes and muxes. It’s not pretty and a bit of a head ****. I appreciate that is the nature of visual programming. Which is why I wondered/supposed/imagined a different way.
These is absolutely zero chance of this happening. Data integrity will always be more important than anything else.
I would just be happy if consolidate wasn’t on by default. I always have to turn it off first thing.