[Bf-animsys] Visualisation Matters

[joe]

Personally, I prefer using simple lines for bones, I don't like there
being anything on the ends at all.  A draw type for this would be
great :)  Also some simple shapes, like circles, cubes, spheres, etc,
and the ability to set a wireframe flag on individual bones.  Of
course, using custom draw types for that sort of thing works as it is
now works just fine too :)

Joe

On Thu, Aug 13, 2009 at 6:02 AM, malefico<malefico at malefico3d.org> wrote:
> 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
>>
>>
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>