[Bf-animsys] Visualisation Matters

Fri Aug 14 02:37:08 CEST 2009

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20090814/ad3c661b/attachment.html>