[Bf-animsys] GPencil: Should onion skins be shown when rendering animations?

[Jeffrey]

Comments inlined:


On 10/23/2016 09:08 PM, Joshua Leung wrote:
> Hi guys,
> 
> A few weeks ago (or was it already several months ago?) Thomas mentioned
> on IRC that it would actually be quite nice to be able to have the
> onionskins still show up in the OpenGL renders.
> 
> == Rationale/Use Cases ==
> 1) You can use the onion skins (with animated before/after frame ranges)
> to get a "cheap" motion blur effect   (Thomas's example). Thinking about
> this, I can imagine how cool this could be to try out...
> 
> 2) If you've animated a shot with the onionskins turned on, you may have
> ended up animating with those in mind. As a result, if you turn off the
> onionskins, you'll find that it doesn't look right as something looks
> "missing". 

I can't say I've ever had a problem animating with onion skin turned on
in any software I've used. Previewing animation in any other software
does not account for onion skin, and those that do have different
default colors for onion skin frames. It is immediately obvious if I
missed a frame while animating, for example, a lick of flame on a log.
In fact, I have default previous- and next-frame colors set up in
blender to be vibrant and unlike my drawing color precisely for this
purpose.

> Then you're stuck with trying to duplicate the frames to a
> second layer to try and recreate that effect manually by offsetting the
> keys....    (This case I've personally experienced -
> https://www.youtube.com/watch?v=IAv9RyvOgCU was animated this way  :)

How often would you really be doing this, though? How much of your
animation is motion blurred enough to require long stretches of onion
skin duplicates? Smear frames and blur should really only be used
sparingly when the action really requires it, and only one or two frames
at a time; the same principle holds true in 3D as well. Otherwise it
ends up looking sloppy.

Along the lines of workflow, I see animating onion skin as potentially a
huge amount of work for very little return. Let's assume you use onion
skin as an effect. You keyframe the number of frames for the effect, but
you need to move a drawing back two frames. Move the drawing, then move
the onion skin keys. If you work with unique pre-/post-frame colors, now
you need to key the colors to get your unique colors back for working.

> == Current Situation ==
> Onion skins get turned off automatically/temporarily when doing
> animation playback or when rendering animations.

Playback and rendering should turn it off, but it is still beneficial to
see onion skin while scrubbing.

> Onion skins gettting disabled during animation playback was one of
> Daniel's feature requests from a while back. IIRC, it makes sense to do
> if you're just using these as a drawing aid (i.e. a "UI feature") as
> you're creating breakdowns/tweaking spacing/etc; you don't want those to
> be visible when doing animation playback or scrubbing around, as then it
> makes it harder to clearly see the poses. For consistency, and since
> it's kindof a "UI tool" (much like motion paths) it was disabled for
> animation renders too.

For more consistency, onion skin would be non-renderable data, like
empties, bones, motion trails, etc. Onion skin should remain a UI tool
as it is now.

> == What should we do? :) ==
> So IMO, it sounds like being able to leave onion skins visible in the
> renders (when coupled with animated onion skin ranges) may actually be
> quite useful for achieving certain special effects. This leaves us the
> question of what to do here:
> 
> 1) Add an extra option to allow keeping onion skins in the renders? Or,
> 2) Don't disable onion skins in the renders?

I would get very frustrated if I had to toggle onion skin every time I
wanted to GL render the viewport. The first thing I would do is script a
toggle. If it must be changed, make it an extra option (like everything
else in blender), so artists can choose for themselves.

> 
> 
> Thoughts?
> 
> Joshua
> 

These are all my opinionated experience.

> 
> 
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> https://lists.blender.org/mailman/listinfo/bf-animsys
> 

-- 
Jeffrey "italic" Hoover