[Bf-animsys] Visualisation Matters

[Bassam Kurdali]

On Thu, 2009-08-13 at 00:37 +1200, Joshua Leung 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 
afaik maya currently allows for this and it would be useful (for me
personally more than ghosting the controls as currently available)
> 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 thnis.
a pointcache modifier would really be quite awesome, not just for
ghosting. it could be useful for keeping scenes responsive with complex
setups that do not need to be recalculated anymore.
> 
> 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' napproach 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)
I think ghosting should be less opaque than the normal mesh, not sure
that wireframe would be nice as the lines can get quite busy (maybe it
should just follow the drawtype).might be cool to have vertex groups
limitation so you can ghost only e.g. the character's head or eyes. not
sure how a pointcache from another object would work?
> 
> 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.
what about disabling subsurf or specific modifiers on the ghosts? that
could be a useful compromise. antother idea would be to have a pick-able
proxy mesh that you use for the ghosts.

another speedup idea for some specific cases might be allowing the user
to specify *not* to re-evaluate a modifier or the entire stack on
frame-change- an example of this is array using curve length where you
rigged the curve: if you have currently a scene with complex usage of
this, it crawls (up to a minute to change frame) even though there is no
animation. a pointcache would solve this, but there is really no need;
just a way to say 'don't evaluate anymore even if the frame changes'
would be enough.

> -------------------------------
> 2) Editing Paths:
> 
this would be supernaturally cool (of course). one of the interesting
side-effects of it is that it would introduce IK-like issues into all
controls; as an example:
imagine you have an FK chain with no IK set up on it, maybe an FK only
arm. The root of the chain is not set, so IK-ing the hand position might
result in undesired motion of a bone that is not even intended to be
keyed by the animator.editing the path of the hand is (I assume) an IK
like operation.
I don't see a solution to this other than riggers paying attention to
their rigs and making sure they don't break in these situations. Maybe
one possiblity is to allow editing IK properties for joints even though
they are not part of an IK constraint chain, since they can be IK'd
anyway (through auto IK and now through the path editing)
> 
> 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... 
> 
I favor instant clicking/draging of the points as opposed to a seperate
mode as my 
> 
> 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.
 usually there will be not that many paths (typically one) visible
(Well, this is my usual case, maybe other people do it differently )
because when you are looking at the paths it can become visually
confusing to have too many. 
> 
> -----------------------------------
> 
> </end long mail>
> 
> Regards
> Aligorith 
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
-- 
PGP public key http://freefac.org/misc/public.key