[Bf-animsys] Visualisation Matters

Thu Aug 13 14:02:11 CEST 2009

Hi, I thought that I could share my thoughts about ghosting features

Ghosting and paths are complementary features for me. When fixing arcs, 
I really beg for something inbetween of those features. For instance, 
paths are slow to calculate and harder to see than ghosts, ghosts works 
on all visible bones so you have to hide most of bones first, but then 
it renders too many things (depending on bone shapes/drawing mode) etc.

I thought it could be useful to have  a way of ghosting only joints. Not 
the whole bone but its root or tail so you could have same thing as a 
path but as fast as ghost.

Another thing I thought was drawing outlines of meshes instead of full 
meshes. It could be either the outline only or a filled outline in 
shades of any colour.

Speaking of visualization bit a bit offtopic here, I also thing it would 
be great to have a few more bone drawing types for bones. An octahedron 
ala Maya, where width of bone is constant, and an even thinner stick 
bone (ideally just a line with two bold joints at root and tail)

Anyway, I'm glad you are considering these stuff !

Regards

malefico

joe wrote:
> Ghosting would be great for working out spacing issues.  I actually
> have a little compositor setup that makes ghosted videos for me, that
> I use to check if the spacing is working.  Having a more advanced
> thing in the 3d view would be much more useful :)  You would need some
> sort of decimation though, and it'd also be important that the
> ghosting show up when rendering opengl preview renders ("playblasts").
>
> Joe
>
> On Wed, Aug 12, 2009 at 5:22 PM, Joshua Leung<aligorith at gmail.com> wrote:
>   
>> On Thu, Aug 13, 2009 at 8:03 AM, William Reynish <william at reynish.com>
>> wrote:
>>     
>>> Hi Joshua,
>>>
>>> Interesting proposal. One of the annoyances of animation in 2.49 was
>>> that these useful visualization options were limited to just bones -
>>> how about enabling these on all objects in 2.5? Being able to directly
>>> adjust the path of the camera, for example, would be very useful. In
>>> fact I hope most of the bone-only features can become more global
>>> (quaternion rotations, for example).
>>>
>>>
>>> On 12 Aug, 2009, at 2:37 PM, 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
>>>>         
>>> IMHO this could be useful in some situations, but most of the time the
>>> output would probably be too messy to be useful. Already with armature
>>> ghosting it's often all but impossible to see what's going on, though
>>> it's not so bad when only ghosting one bone at a time. From where I
>>> stand this is honestly not that interesting a feature, but this is:
>>>       
>> Regarding the cluttering problems, I believe that this is mainly a result of
>> the use of wireframes. In the proposal I made, you'd be drawing the meshes
>> as solid all the time, and with varying opacity, so that would be less of a
>> problem IMO. Also, this is where the comment about needing adaptive + usable
>> decimation comes in. As you take steps away from the current time, the
>> ghosts become less visible, and the amount of detail required should
>> probably taper off too. This could reduce complexity (visually, and also for
>> performance considerations).
>>
>>     
>>>> 2) editing of the path verts
>>>>         
>>> This would be simply incredible. This would be fantastically useful,
>>> esp if you could edit bezier path curves in 3D. I'm sure it's not easy
>>> though. I'd definitely advocate to not introduce yet another mode, and
>>> let the user just select curve points and translate them. You are
>>> right that you'd only want to tweak one or a few bones at a time, but
>>> you could instead have a toggle for each bone to display its animation
>>> curve on or off. I don't follow what the problem would be of letting
>>> this be editable within pose mode (or even object mode for objects?).
>>> What ' established expectations' are violated?
>>>
>>> Cheers,
>>>
>>> -William
>>>       
>> The main (technical) problem is really deciding if bones or path verts
>> should get selected. My comment about 'established expectations' being
>> violated stems from this: No other mode in Blender supports selection (and
>> editing) of more than one 'class' of data (i.e. in Object mode, you're only
>> working with Objects, not Objects+Verts, while in Edit Mode, you're only
>> working on the vertices of the active Object). Secondly, if we allowed the
>> data to be edited only by click-drag on the path verts, we'd have the
>> limitation that you could only edit one vert at a time (i.e. multi-select +
>> all the normal selection tools we have wouldn't work), and similar problems
>> apply to transforms.
>>
>>     
>>>> 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.
>>>>         
>>>
>>> _______________________________________________
>>> Bf-animsys mailing list
>>> Bf-animsys at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-animsys
>>>       
>> _______________________________________________
>> Bf-animsys mailing list
>> Bf-animsys at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-animsys
>>
>>
>>     
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>   