[Bf-animsys] Visualisation Matters

[Nathan Vegdahl]

I second William's point: many of the visualization options right now
are specific to bones, and it would be absolutely fantastic if they
could be generalized to objects.  It would be great, for example, to
be able to visualize the path of a bouncing ball without having to
create an armature for it.

(In fact, on a larger scale, the more we can move towards making all
animation tools agnostic to whether you're working with bones or
objects, the better.  IMO, at least.)

> At the time of writing, there are two big "holy grails" that would be nice
> to have:
> 1) ghosting of the actual meshes deformed by the armatures, and

   As far as I'm concerned, the ghosting "holy grail" isn't just
meshes, it's generalized ghosting for all objects.  So, for example,
select any object (be it a mesh, an empty, or a nurbs curve) and tell
Blender "ghost this".  (Again, this goes with the theme of
type-agnostic animation tools.)
   But having said that, mesh ghosting is definitely the most important.

   Also keep in mind that ghosting must work for library linked
characters with proxy armatures, otherwise it's useless for most
productions (such as up-coming Durian).  For this reason especially,
I'm skeptical of the modifier-based approach you propose, since the
mesh will actually still be part of a linked group in those cases.  It
might be best to tackle ghosting from a more object-type agnostic
standpoint from the beginning, for reasons like this.

   Regarding the cluttering problems William mentioned, I think this
depends heavily on how the meshes are drawn.  Having a "silhouette"
drawing mode, for example, where the mesh is drawn as single un-shaded
color, would make ghosting very clear.  And as Aligorith said, even a
normal shaded drawing would present some clarity.  And especially if
the user can choose a separate draw type for the ghosts vs the real
mesh, it could make for some very clean visualizations.

   I think it also depends on how the animator plans to use it.  If
you're imagining 20 frames of ghosting, then yes it is going to be
confusing.  But in XSI I used only 1-2 ghosted frames on either side
of the current frame.  It was a *huge* benefit for working out
break-down poses, among other things.  Especially in combination with
stepped key interpolation.  And having an option to ghost only on
frames with keys would be fantastic for blocking, I suspect.
   The usefulness of ghosting also just generally depends on what
you're animating.  If you're animating a talking-head shot, it's going
to be useless.  But if you're animating an exuberant dance move or a
wrench clattering to the ground, then it's going to be of a lot more
utility.

> 2) editing of the path verts

   For me personally, editing individual verts isn't so much of an
advantage, since I can do that by going to the relevant frame and
moving/rotating the object/bone directly.  It would still be useful,
and would speed up workflow a bit.  But it wouldn't be as fundamental
an improvement as, say, being able to edit ease-in-ease-out in the 3d
viewport.
   Also, developing a good way to visualize rotations over time in the
3d viewport would be of huge benefit.  Paths only track translation of
a point (even if it's a point on a rotating bone).  If we could figure
out a way to visualize full 3d rotations, that would be amazing.

   For me at least, the general goal is to get animation out of graph
editors and into the 3d viewport, wherever possible.  So anything that
helps move towards that, I will drool over. ;-)

--Nathan V

On Wed, Aug 12, 2009 at 5:37 AM, Joshua Leung<aligorith at gmail.com> wrote:
> Hi all,
>
> Once again, it's that time of the year when I start looking into doing
> another incremental round of improvements on the visualisation features -
> i.e. ghosting and paths in particular.
>
> At the time of writing, there are two big "holy grails" that would be nice
> to have:
> 1) ghosting of the actual meshes deformed by the armatures, and
> 2) editing of the path verts
>
>
> Below are some notes on how these could possibly be implemented. Comments on
> the suitability of these methods, or even proposals for better systems are
> welcome.
>
> ---------------------------------
> 1) Ghosting meshes:
> A rather crude approach to this would be to simply draw the mesh posed by
> the armature in different ways at several different frames, if a given mesh
> has an armature parent (and an armature modifier). This would not work for
> normal animated objects, and would be really slow.
>
> However, the approach I'm currently thinking of would require about 3 parts:
> a. Pointcache modifier - used for baking armature,etc. deforms on points to
> cached data. The advantage here is that if done right, we could look forward
> to some improved playback speeds in some cases. It would also make some
> effects (such as 'smear' visualisation - see Pigeon Impossible Blog for
> details) possible, since those effects depend on stuff like this.
>
> b. Ghost/Motionblur instancer modifier - this modifier uses the pointcache
> (a), to get the mesh data at another frame and draw it as part of the mesh
> (probably with different material settings?). It would be able to therefore
> be used for both armature and object-level animation, and could be used to
> give more control over what gets ghosted by making the user explicitly
> define what to ghost. Probably a pointcache from another object could even
> be used in some cases? Maybe for motionblur during rendering, this modifier
> could also act as a more 'in camera' approach to motionblur rendering?
> (chances are, renderers wouldn't cope with having predefined meshes
> specially for motionblur being created, as they'd treat the meshes as extra
> data)
>
> c. Improved decimator - I'm aware that Genscher was working on something
> along these lines? Basically, this is only an optional part of the setup,
> but could potentially be hooked up with the ghost-modifier to decrease the
> complexity of the mesh over time. Of course, this may not be practical as it
> is likely to be too slow to be useful, clumsy to setup, and/or cause
> problems with the overall shape of the mesh which may not be desired.
>
> -------------------------------
> 2) Editing Paths:
> There are two big obstacles here: figuring out how to map path edits to
> transforms (rotations vs scaling vs location), and how to allow the user to
> start editing the path vertices.
>
> The first issue is relatively trivial, and is really just a matter of
> further investigation I guess.
>
> However, I need some suggestions for the second problem. As I currently see
> it, most people would prefer to be able to just click on some path vertex
> and then move it by simply dragging, all without having to go into any
> special sub-modes or so. There are several disdvantages of this, namely that
> it practically violates many of the established expectations of how users
> usually expect to be able to interact with elements with editable vertices
> in Blender (selection + transform tools are limited). Also, this would
> complicate pose-mode event handling in particular, since we'd have to deal
> with priority of bones vs curve verts too...
>
> However, if we went with the "separate mode" approach, it becomes a bit more
> frustrating to try and edit the paths of a few bones, especially if you
> wanted to edit the paths of different bones but didn't want to have to stop
> and think which ones you'd like to isolate for editing. Just clarifying that
> a bit, I'm thinking that with this separate mode, you'd select one or more
> bones with some paths, enter the mode, and only be able to tweak the path
> vertices of the bones selected when entering the mode. Then, when those
> paths were tweaked ok, you could exit the mode, and continue editing other
> parts. This might be an acceptable compromise, given that when editing a
> path, I'm assuming that you're going to only concentrate on the motion of a
> few limbs/controls at a time.
>
> -----------------------------------
>
> </end long mail>
>
> Regards
> Aligorith
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>