[Bf-committers] Functionality board
Sun, 15 Jun 2003 23:53:10 +1000
Do you mind if I re-post this message to the functionality board mailing
Alternatively you (and anyone else that's interested!) can come and join up
yourself to chat about these things:
http://www.blender.org/mailman/listinfo/bf-funboard . Coders are of course
more than welcome and encouraged to join in the discussions (though
discussion is kept non-technical).
----- Original Message -----
From: "Charles Wardlaw" <firstname.lastname@example.org>
Sent: Sunday, June 15, 2003 11:39 PM
Subject: Re: [Bf-committers] Functionality board
> > -- Right-mouse select, replace with context driven menus?
> > We can think over a new organization of default mousebutton
> > behaviour. Contextual menus can be a great aid in learning
> > and using Blender.
> I'm not so sure about this. It might be best to add a "Context" menu
> to the toolbox. It's just that the right-click selecting in Blender
> has become second nature to me and to a number of other users; changing
> this might cause the wrong kind of stir in the community.
> Another option is to morph the toolbox into something more like what's
> found in 3DS Max -- it tends to let different actions fall into
> quadrants. IE, on a cartesian plane the current toolbox would render
> in quadrant I, while context menues would render in quadrants II, III,
> and IV, depending on the current editing mode. This would allow for
> multiple context menues, for things like mesh editing, texture
> assignment, and so on.
> > -- General make-over of interface
> > I won't support real 'skinning', but the general looks of the
> > interface can be easily upgraded to a more contemporary looks.
> > It's a real designer's thing to do! If multiple great make-overs
> > are proposed, we can implement a user-preset for them.
> Are you thinking of completely programmatic skins, or skins loadable
> from, say, PNG files in the ~/.blendrc/ folder or
> If it's simple images, I can see a lot of non-programmers jumping on
> the band wagon to create skins. There'd be a lot of bad ones, but also
> a lot of really good ones that could be distributed with Blender, with
> author's permission.
> > -- Wireframe colors
> > We can review how it currently works in Blender, and come with a
> > proposal how it gives a bit more control and visual feedback.
> > This should also include thinking over how 'solid drawing' will
> > be handled.
> Yeah, I've always thought that the wireframe colors should reflect
> object colors, as solid drawing mode does. The selected object would
> then need some other way to distinugish itself from the rest, however.
> I forget how Max does this; it might have been with some kind of
> handles or a little selection widget. Or maybe it's as simple as
> displaying the object's axes when an object's selcted; this could tie
> into the manipulator handles you mentioned in "MEDIUM COMPLEX."
> > -- Manipulator (handles) for transform
> > As an aid to vizualize selection status and rotation/scale
> > values, a manipator can be drawn which of course allows
> > scaling/rotating as well.
> This would be a wonderful addition. The current system for locking
> movement and scaling/rotation to an axis is a little hodge-podge.
> Adding in manipulator handles / axes would be greatly appreciated.
> > -- External Render integration
> > With the impressive improvements in Yafray, we should start with
> > them a project how a good collaboration (interface) with their
> > render system can be achieved. Same applies for 3Delight or
> > Renderman of course.
> As those projects mature, would the current blender render system be
> maintained/updated? (Especially with Cessen's new additions?) Also,
> if any of the renderers provide a linkable library, what about
> including the functionality directly inside Blender?
> > --- Buttons & headers, better user configurable organisation
> > Like some menus that pop up now (NKEY) we can make them become
> > persistant and movable. This will allow users to add
> > menus/buttons to each window in Blender. Think for exampe of
> > Ipo settings, View3d settings, NLA window buttons, etc. The
> > same structure can be appplied to the ButtonsWindow itself,
> > grouping them in 'blocks' and let the user arrange or collapse
> > them. Additional to that, the headers system can be extended
> > to a verticial user-configurable one. The horizontal then
> > remains 'standard'.
> The one problem I have with this idea is interface clutter. My
> personal experience with systems using such an interface is that it
> leads to a lot of wasted space on-screen (with the extra handles and
> titlebars that are required per dockable box). Take Flash, for
> example. It does not run happily in 1024x768; you have to continually
> swap between multiple boxes, minimizing some to access others. The way
> blender works currently, such swapping is mostly non-existent, and the
> FKeys allow the access of the important function buttons.
> > -- Constraints: replacing parenting and tracking
> I don't know anything about constraints. What I'd like to see is an
> arrowhead on parenting lines that indicates the relationship between
> two objects. In complex scenes with lots of parents, it sometimes gets
> On Python: the trick with adding it to the main program loop is speed.
> In comparisons I've done with other scripting languages it's a bit
> pokey, and if a large number of python commands are getting run every
> frame or every other frame, it could lead to a severely slow interface.
> Now, since python would make having undo functionality a snap (the
> code's already done, as I recall), and since the python code and the
> blender code already both access the same underlying structures, it
> might be nice to have a queue of python commands, where during the
> update phase of the main loop (and before drawing) python checks to see
> if it has anything to do, does it, and empties its instruction queue.
> Or maybe I'm over thinking things.
> - Charles
> Bf-committers mailing list