[Bf-animsys] Visualisation Matters

[joe]

Eh I'm not sure you read me right.  I *do * use custom draw types.
The stick drawtype isn't enough, no, not for me anyway (I find it too
distracting), so I modeling a simple wire drawtype myself, and also
some cubes/circles/etc.  And I do know about the W button, what I
wanted is for it to affect non-custom-drawtypes too.

Joe

On Thu, Aug 13, 2009 at 6:37 PM, Joshua Leung<aligorith at gmail.com> wrote:
> Joeedh,
>
> On Fri, Aug 14, 2009 at 12:44 AM, joe <joeedh at gmail.com> wrote:
>>
>> 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 :)
>
> So the stick drawtype is not enough?
>
>>
>>   Also some simple shapes, like circles, cubes, spheres, etc,
>
> You could currently use the custom draw types for that - the code is in
> place for empties and could be really easy to port if there really was a
> need.
>
>>
>> and the ability to set a wireframe flag on individual bones.
>
> The mysterious 'W' button beside the custom draw type field (in 2.4x that
> is... 2.5 not sure what it's name is).
>
>>
>> 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
>> >
>> _______________________________________________
>> 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
>
>