[Bf-funboard] Blenders look and functionality
Clinton Baldridge
bf-funboard@blender.org
Sun, 28 Sep 2003 00:13:42 -0400
Blender is a unique, if not unusual program. It is and has been very strait
forward in it's shortcuts and interface. It isn't all prettied up with
alot of fancy graphics that suck memory and speed. It just does what you
want it to do without a lot of rubbish, clutering your workflow. In fact
it's simplicity and uniqueness are it's greatest strenths (aside from it
being free).
What I'm trying to say is that putting fancy pop-up tool menus and cool
graphics in Blender may look pretty, but they are completly unnesessary. I
not trying piss in anyones cornflakes, but Blender's interface is very fast
and very functional for modeling 3d scenes. For me, once I learned the
Blender interface, I found it to be a lot more efficent than a typical
Windows sort of program. For me personally the fact that it so Unix like,
and not all like sissy Windows, is part of the reason I like to use Blender.
I'm not saying that adding new key shortcuts is bad Idea, however changing
them changing from what they are now for a given function is
counterproductive. There are alot key combinations to go around, why not
make life easy for long time Blender users everywhere.
I think the only justifiable reason to change anything about the interface
of Blender, is in the presence of new functionallity. Otherwise it is waste
of time, and a damned shame really.
I can see making the interface different for the 3.0 release, but it again
there is really now point. I believe in the K.I.S.S. method (Keep It Simple
Stupid).
Please, do not take what I am saying as inflammatory. I just think we
should worry about what we can make Blender do, not what we can make it look
like. Blender's interface is great the way it is and If it's not broke don't
fix it.
Clinton
>From: bf-funboard-request@blender.org
>Reply-To: bf-funboard@blender.org
>To: bf-funboard@blender.org
>Subject: Bf-funboard digest, Vol 1 #118 - 9 msgs
>Date: Sun, 28 Sep 2003 00:03:00 +0200
>
>Send Bf-funboard mailing list submissions to
> bf-funboard@blender.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
> http://www.blender.org/mailman/listinfo/bf-funboard
>or, via email, send a message with subject or body 'help' to
> bf-funboard-request@blender.org
>
>You can reach the person managing the list at
> bf-funboard-admin@blender.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Bf-funboard digest..."
>
>
>Today's Topics:
>
> 1. Re: workflow / reworking of ctrl-t, ctrl-p, ctrl-c, etc (The Fallen
>Weeble)
> 2. Re: Re: Reworking of ctrl-t, ctrl-p, ctrl-c, etc.... (David)
> 3. (reply to David Cuny & Groo) Ctrl-T, Ctrl-P, etc (Luke Wenke)
> 4. Re: (reply to David Cuny & Groo) Ctrl-T, Ctrl-P, etc (The Fallen
>Weeble)
> 5. Re: workflow / reworking of ctrl-t, ctrl-p, ctrl-c, etc (Guillermo
>S. Romero / Familia Romero)
> 6. Re: Default material, lamp, and camera types in .B.blend (Guillermo
>S. Romero / Familia Romero)
> 7. Re: (reply to David Cuny & Groo) Ctrl-T, Ctrl-P, etc (Ton
>Roosendaal)
> 8. Re: (reply to David Cuny & Groo) Ctrl-T, Ctrl-P, etc (Ton
>Roosendaal)
> 9. Re: Nvidia Cg Shaders (Clinton Baldridge)
>
>--__--__--
>
>Message: 1
>Date: Sat, 27 Sep 2003 10:20:14 -0400
>From: The Fallen Weeble <flaw@misaligned.net>
>To: bf-funboard@blender.org
>Subject: Re: [Bf-funboard] workflow / reworking of ctrl-t, ctrl-p, ctrl-c,
>etc
>Reply-To: bf-funboard@blender.org
>
>Not to butt into the discussion, but I think that while your intents are
>honorable you might be barking up the wrong tree. IMO, the
>"active"/"selected" thing needs to be clarified a bit.
>
>1. "Active non-selected" probably shouldn't exist as a state at all.
>
>2. There should be a strong visual representation of that. The Red and
>Blue idea you suggested is a bit drastic, but it's the right idea. We
>can probably do something with the existing colors for selected objects,
>but make the Active object even more distinguished (like white, since we
>all ready use that for objects we are acting upon - like when
>translating, rotating, or scaling).
>
>As far as your list of objects popping up when doing a Track or Parent
>action, I think the intention is good, but it will probably confuse more
>new users than clarify things for them. Currently, it's pretty
>straight-forward: select the stuff you want to work on, select the
>active object, issue the command, confirm. With your suggestion, it
>actually adds ambiguity to the situation. A user (new or otherwise)
>would initially view your pop-up list and say "Whoa! What's all this
>stuff?" You're giving a bunch of extra options and information that you
>don't need to. The fact, also, that many users (especially new ones)
>don't give their objects meaningful names also confuses the issue,
>with or without visual feedback like the highlighting you suggest.
>
>I think clarifying what is active and selected as well as making the
>confirmation dialog a bit more clear (but keeping it simple!) would
>effectively make this a non-issue.
>
>Then again, that's just what I think.
>
> Groo
>
>On Sat, Sep 27, 2003 at 10:15:25PM +1000, Luke Wenke wrote:
> > Hi Matt,
> > > I think some of these discussions may be getting on to the wrong track
>a
> > > bit, as some of the suggestions seem a bit un-blenderish to me.
> > -----------------
> > I am exploring methods that are easier for beginners to understand while
>at
> > the same time are good for power-users. BTW, I've addressed many of the
> > problems you mention before... so I may sound like I'm repeating myself.
> >
> > > The Blender workflow seems intuitive and visual, and I fear that
>choosing
> > object names
> > > from lists etc. is quite opposite to that Blender 'feeling'. When I'm
> > > working I generally don't tend to name my objects (lazy perhaps?), but
> > work
> > > in the viewport. I remember something by the way it looks and it's
> > position,
> > > not by a name.
> > -----------------
> > As I said, when you are hovering your mouse over the names of the items,
>the
> > corresponding 3d object would be highlighted (perhaps in all available
> > views). You can move through the list quickly to see the objects
>highlight
> > and show themselves...
> > Or you can choose the active item like you normally do.
> >
> > This is how ctrl-T currently works:
> > 1) select some things
> > 2) make sure the right thing is active
> > 3) ctrl-T
> > 4) left-click without moving the mouse (or click elsewhere or esc to
>cancel)
> >
> > And you can do exactly the same thing using my method!
> > Except that instead of the menu saying:
> > =========
> > *OK?* (bold)
> > Make Track
> > =========
> >
> > It would now say:
> > =========
> > *Track...* (bold)
> > active-item1
> > -----------
> > other-selected-item1
> > other-selected-item2
> > =========
> >
> > And instead of the mouse beginning over the word "Make Track", it will
> > appear over "active-item1" (or whatever the active item is called).
> >
> > And you can still cancel in exactly the same way to the old method. (esc
>or
> > move or click outside the menu)
> >
> > -----------------
> > > Although Luke's method may seem just as fast (same number of mouse
> > clicks),
> > > it wouldn't be in practise, as the more inconsistency means that the
>user
> > > must spend more time remembering for a split second "oh I have to
>choose
> > the
> > > selection *afterwards* for this command" rather than just doing it
> > > naturally, the same was as everything else.
> > -----------------
> > If implemented, it should be done consistently involving all the
>relevant
> > functions of blender.
> >
> > BTW, I see g/r/s as being quite different - they only involve the
>selected
> > items, and if the active item isn't selected (it is possible to select
>other
> > things while the active thing is unselected) then the active item is
> > ignored. On the other hand, ctrl-t, etc, always use the active item,
>whether
> > it is selected or not.
> > The g/r/s functions only involve one group of objects.... ctrl-t,
>ctrl-p,
> > etc, use two groups of objects (the active item and the non-active
>selected
> > items). Also, there is no pop-up menu to confirm g/r/s like ctrl-t,
>etc...
> > so they are quite different in blender.
> >
> > > Although it's not as consistent as it probably should be, to me, it
>seems
> > > that most Blender tools work in a way like:
> > >
> > > 1. Select something to operate on
> > > 2. Invoke command (via hotkey/toolbox/menu/whatever)
> > > 3. Optionally visualise or predict what will happen either
>interactively
> > > (like move/rotate/scale) or non-interactively with a confirmation
>dialog
> > > with an opportunity to cancel/undo the command
> > > 4. Confirm or cancel the command
> > ======================
> > My idea has those steps, except that the active item can be changed in
>steps
> > 3 and 4 (by moving the mouse before you click or press enter). And as
>said
> > earlier you can still just select the active item in step 1 or cancel
>the
> > operation after you've press ctrl-T (using esc, etc).
> >
> > > I think this sort of workflow is why Blender is quite usable without
>an
> > > 'undo' function. Rather than letting the user do things, mess up and
>undo
> > > it, Blender often gives a way out before enacting the command in the
>first
> > > place. It's like that Raskin UI theory of always giving people an exit
>or
> > a
> > > way to undo - Blender often does it, but more integrated with the
>workflow
> > > rather than as a separate command.
> > -----------------
> > As said earlier, that is part of my idea.
> >
> > > To be consistent with this, I like beatabix's suggestion:
> > > 1. Select the objects as usual, with one active
> > > 2. Invoke track command (via hotkey/toolbox/menu/whatever)
> > > 3. Display a confirmation along the lines of "Track selected to
><active
> > > object's name>" and at the same time, draw the helplines (perhaps
> > partially
> > > transparent?) from the selected objects to the active object so you
>can
> > visu
> > > alise what will happen when you confirm the command.
> > > 4. Confirm or cancel the command.
> > -----------------
> > My idea is virtually identical to that except step 3 isn't ambiguous.
>You
> > aren't actually Tracking the selected items to <active item>.... you are
> > only tracking the selected non-active items to the active item.
> >
> > My popup menu would look like this (with the mouse beginning on the the
> > active object's name):
> > *Track....* (bold - since it is a key word)
> > <active item> <-(mouse pointer starts here)
> > ------------
> > <other selected item 1>
> > <other selected item 2>
> > <other selected item 3>
> >
> > While their mouse is hovering over active item's name, the "helplines"
>you
> > describe in (3) could be drawn.
> >
> > Then you left click on <active item> (it's name in the menu, where the
>mouse
> > already is) to confirm. (or press esc - or select something else, while
>at
> > the same time the objects change to reflect which one is the new active
> > object)
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard@blender.org
> > http://www.blender.org/mailman/listinfo/bf-funboard
>
>--__--__--
>
>Message: 2
>From: David <dcuny@lanset.com>
>To: bf-funboard@blender.org
>Subject: Re: [Bf-funboard] Re: Reworking of ctrl-t, ctrl-p, ctrl-c, etc....
>Date: Sat, 27 Sep 2003 08:20:01 -0700
>Reply-To: bf-funboard@blender.org
>
>Luke Wenke wrote:
>
> > (Hotkey lists usually don't give you enough
> > information - they'd just say ctrl-P is "make parent"
> > or "parent" - they don't explain the significance of darker
> > and lighter selections)
>
>I always had trouble remembering the order of this operation. Does it mean
>that you are going to make something *into* a parent, or make a parent
>*for*
>it?
>
>Perhaps the language could be clarified.
>
>-- David Cuny
>
>--__--__--
>
>Message: 3
>From: "Luke Wenke" <iljwamh1234567890@hotmail.com>
>To: <bf-funboard@blender.org>
>Date: Sun, 28 Sep 2003 01:55:02 +1000
>Subject: [Bf-funboard] (reply to David Cuny & Groo) Ctrl-T, Ctrl-P, etc
>Reply-To: bf-funboard@blender.org
>
>David Cuny wrote:
> > I always had trouble remembering the order of this operation. Does it
>mean
> > that you are going to make something *into* a parent, or make a parent
>*for*
> > it?
> > Perhaps the language could be clarified.
>----------------------------------
>Yeah that was exactly my original problem.... and also my initial
>solution... then my solution involved separating the parents and the
>children more.
>
>Currently the "Make Parent" popup says:
>--------------
>OK?
>Make Parent.
>--------------
>
>My suggestion would be something like:
>--------------
>Make activeobject the parent?
>OK
>--------------
>Where you click on "OK" to confirm, rather than "Make Parent".
>"activeobject" is the name of the active object (light pink).
>==============================================
>
>Groo:
> > Not to butt into the discussion, but I think that while your intents are
> > honorable you might be barking up the wrong tree. IMO, the
>"active"/"selected" thing needs to be > clarified a bit.
> > 1. "Active non-selected" probably shouldn't exist as a state at all.
>I agree, but I was pointing out that currently in blender it is a state.
>(Though it is pretty hard to find that out)
>
> > 2. There should be a strong visual representation of that. The Red and
> > Blue idea you suggested is a bit drastic, but it's the right idea. We
> > can probably do something with the existing colors for selected objects,
> > but make the Active object even more distinguished (like white, since we
> > all ready use that for objects we are acting upon - like when
> > translating, rotating, or scaling).
>Yeah, I think white is the next best colour besides red to show that it is
>the focus.... the other selected objects could be their regular pink I
>guess...
>
>
> > As far as your list of objects popping up when doing a Track or Parent
> > action, I think the intention is good, but it will probably confuse more
> > new users than clarify things for them.
>I thought it would be self-explanatory.... the title of the pop-up menu
>would say "Track..." and to complete the sentence they'd just pick one of
>the objects. (This means "track that thing") The parent one could be
>"Choose
>the parent...." or "Make parent from..." and they just choose the parent,
>etc. I think it clarifies things a lot compared to the present situation.
>At
>the moment you can do ctrl-p with nothing selected - or just the active
>object selected and nothing else... and you can go to "Make parent"... and
>then notice that the object doesn't behave any differently. Or they could
>select one object and do ctrl-T and "Make Track"... that could mean that
>the
>selected object is a "track". (They just made a track - "track" should be
>used as a verb in the pop-up menu) And blender doesn't tell them exactly
>which selection (the light one or darker ones) does what in the tracking...
>(unless they test it later)... (see the beginning of this message for more
>about that)
>
> > Currently, it's pretty straight-forward: select the stuff you want to
>work
>on, select the
> > active object, issue the command, confirm.
>But it isn't clear (especially if you're only used to using 2 objects)
>whether the active object tracks the other object or vice-versa - and
>whether the active object becomes the parent of the other object or
>vice-versa... it just says "Make Track" and "Make Parent" ("Make Track" is
>particularly ambiguous)
>
> > A user (new or otherwise) would initially view your pop-up list and say
>"Whoa! What's all this
> > stuff?"
>See earlier reply... the title of the pop-up would ask them a question or
>say "Track..." and that implies that the user has to complete the sentence
>by choosing a thing to track.
>
> > You're giving a bunch of extra options and information that you don't
>need
>to.
>The active object name would be at the top and separated from the rest of
>the names. If the objects are physically all bunched up, it would be easier
>to pick the one you want using the menu (you could also see the objects
>being highlighted as you go through the list)
>
> > The fact, also, that many users (especially new ones) don't give their
>objects meaningful names also > confuses the issue, with or without visual
>feedback like the highlighting you suggest.
>The user can just move the cursor over the list until the right object is
>highlighted - even without reading the object titles very closely. Or they
>can choose the active object before they press ctrl-t, etc, like they'd
>currently do.
>
> > I think clarifying what is active and selected as well as making the
> > confirmation dialog a bit more clear (but keeping it simple!) would
> > effectively make this a non-issue.
>Note that the active thing can be selected as well (you make it seem like
>active and selected objects are mutually exclusive...) when you're using
>g/r/s, etc the active selection acts just like any other selection...
>
> > Then again, that's just what I think.
>Well thanks for your thoughts... as I said, white would be my next best
>choice for the selected active objects... (maybe when it is active but not
>selected it could have a white centre).
>
>- Luke.
>
>--__--__--
>
>Message: 4
>Date: Sat, 27 Sep 2003 12:45:13 -0400
>From: The Fallen Weeble <flaw@misaligned.net>
>To: bf-funboard@blender.org
>Subject: Re: [Bf-funboard] (reply to David Cuny & Groo) Ctrl-T, Ctrl-P, etc
>Reply-To: bf-funboard@blender.org
>
>Whew... alright, this is what I propose (and I apologize because I think
>there have been a few too many proposals already, but...) is as follows:
>
>1. The basic process remains as is (select objects, select active, issue
>command, confirm).
>
>2. The "Active" state is a subset of the "Selected" state.
>
>3. Objects in the "Active" state should have a more distinguishing color
>(suggest white).
>
>4. Parenting and tracking on single objects should return an error since
>it doesn't make logical sense (suggest "Error: must have more than one
>object selected").
>
>5. Confirmation dialog should have more clear language (suggest "Make
>Active Object Parent" and "Track Active Object").
>
>Can we agree to use this as a starting point and go from there? Right
>now we're doing a lot of needless running in circles and repeating
>ourselves. Luke, while it remains to be seen whether or not your
>confirmation/selection dialog would add or detract, I think it would be
>a good idea to see how this works out. If it substantially clears up
>the issue (as I think it will), then we're cool. If not, we can move
>from there with other approaches such as yours.
>
>I apologize if I sound like I'm talking for the active developers, but I
>think this would be a feasible way to go and shouldn't be too difficult
>to implement. I wouldn't mind trying, but I'm pretty sure someone more
>familiar with the codebase could get it done faster. However, if anyone
>wants to send me an email, pointing me in the right direction, I'll see
>if I can't do anything.
>
>Let's get this resolved and move on.
>
>Later.
>
> Groo
>
>
>--__--__--
>
>Message: 5
>Date: Sat, 27 Sep 2003 19:24:57 +0200
>From: "Guillermo S. Romero / Familia Romero" <famrom@infernal-iceberg.com>
>To: bf-funboard@blender.org
>Subject: [Bf-funboard] Re: workflow / reworking of ctrl-t, ctrl-p, ctrl-c,
>etc
>Reply-To: bf-funboard@blender.org
>
>iljwamh1234567890@hotmail.com (2003-09-27 at 2215.25 +1000):
> > It would now say:
> > =========
> > *Track...* (bold)
> > active-item1
> > -----------
> > other-selected-item1
> > other-selected-item2
> > =========
>
>I am going to love a menu with 100+ items. :]
>
>Can we just make the active item clearer in non-wire modes? That
>should be enough.
>
>GSR
>
>
>--__--__--
>
>Message: 6
>Date: Sat, 27 Sep 2003 19:30:54 +0200
>From: "Guillermo S. Romero / Familia Romero" <famrom@infernal-iceberg.com>
>To: bf-funboard@blender.org
>Subject: [Bf-funboard] Re: Default material, lamp, and camera types in
>.B.blend
>Reply-To: bf-funboard@blender.org
>
>ton@blender.org (2003-09-26 at 2325.14 +0200):
> > For a default .B.blend, we better provide a nice range of Materials,
> > which have all basic types setup very well; 'metal', 'plastic',
> > 'envmap' for example. A user then just browses one of these defaults,
> > and tweaks it. The Materials can can get a 'fake user' to make sure no
> > Objects are needed to use it.
>
>About Materials, sutabi (irc nick) was working in a nice kit of
>materials. It could be a start, for .B.blend or for a lib. Maybe
>crowding the .B.blend is too much, but shipping a lib maybe not (also
>serves as import function tutorial/demo).
>
>BTW, I forgot I had updated the .B.blend:
>http://www.infernal-iceberg.com/blender/gsr-2.28-.B.blend.bz2
>
>GSR
>
>
>--__--__--
>
>Message: 7
>Date: Sat, 27 Sep 2003 18:57:06 +0200
>Subject: Re: [Bf-funboard] (reply to David Cuny & Groo) Ctrl-T, Ctrl-P, etc
>From: Ton Roosendaal <ton@blender.org>
>To: bf-funboard@blender.org
>Reply-To: bf-funboard@blender.org
>
>Hi,
>
>Thanks Groo. I agree with the below summary. we can also look at
>including the object name in the dialog, although it should remain
>easily readable.
>
>I'd prefer to store this info at a todo list, because it also has a
>relation to a couple of other issues:
>
>- wireframe colors
>- conventions for mousebuttons
>- the new context sensitive toolbox
>- configurable hotkeys
>
>I doubt we can implement all issues for 2.30 (end of oct) though. My
>proposal is to first solve the main topics as described in the UI doc
>(menus, buttons, toolbox, looks) and then move on to all the other
>issues.
>
>Nevertheless, discussions and design proposals remain welcome here.
>Good to be ready before a coder starts hacking, er! :P
>
>-Ton-
>
>
>On Saturday, Sep 27, 2003, at 18:45 Europe/Amsterdam, The Fallen Weeble
>wrote:
>
> > Whew... alright, this is what I propose (and I apologize because I
> > think
> > there have been a few too many proposals already, but...) is as
> > follows:
> >
> > 1. The basic process remains as is (select objects, select active,
> > issue
> > command, confirm).
> >
> > 2. The "Active" state is a subset of the "Selected" state.
> >
> > 3. Objects in the "Active" state should have a more distinguishing
> > color
> > (suggest white).
> >
> > 4. Parenting and tracking on single objects should return an error
> > since
> > it doesn't make logical sense (suggest "Error: must have more than one
> > object selected").
> >
> > 5. Confirmation dialog should have more clear language (suggest "Make
> > Active Object Parent" and "Track Active Object").
> >
> > Can we agree to use this as a starting point and go from there? Right
> > now we're doing a lot of needless running in circles and repeating
> > ourselves. Luke, while it remains to be seen whether or not your
> > confirmation/selection dialog would add or detract, I think it would be
> > a good idea to see how this works out. If it substantially clears up
> > the issue (as I think it will), then we're cool. If not, we can move
> > from there with other approaches such as yours.
> >
> > I apologize if I sound like I'm talking for the active developers, but
> > I
> > think this would be a feasible way to go and shouldn't be too difficult
> > to implement. I wouldn't mind trying, but I'm pretty sure someone more
> > familiar with the codebase could get it done faster. However, if
> > anyone
> > wants to send me an email, pointing me in the right direction, I'll see
> > if I can't do anything.
> >
> > Let's get this resolved and move on.
> >
> > Later.
> >
> > Groo
> >
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard@blender.org
> > http://www.blender.org/mailman/listinfo/bf-funboard
> >
> >
>------------------------------------------------------------------------
>--
>Ton Roosendaal Blender Foundation ton@blender.org
>http://www.blender.org
>
>
>--__--__--
>
>Message: 8
>Date: Sat, 27 Sep 2003 18:57:06 +0200
>Subject: Re: [Bf-funboard] (reply to David Cuny & Groo) Ctrl-T, Ctrl-P, etc
>From: Ton Roosendaal <ton@blender.org>
>To: bf-funboard@blender.org
>Reply-To: bf-funboard@blender.org
>
>Hi,
>
>Thanks Groo. I agree with the below summary. we can also look at
>including the object name in the dialog, although it should remain
>easily readable.
>
>I'd prefer to store this info at a todo list, because it also has a
>relation to a couple of other issues:
>
>- wireframe colors
>- conventions for mousebuttons
>- the new context sensitive toolbox
>- configurable hotkeys
>
>I doubt we can implement all issues for 2.30 (end of oct) though. My
>proposal is to first solve the main topics as described in the UI doc
>(menus, buttons, toolbox, looks) and then move on to all the other
>issues.
>
>Nevertheless, discussions and design proposals remain welcome here.
>Good to be ready before a coder starts hacking, er! :P
>
>-Ton-
>
>
>On Saturday, Sep 27, 2003, at 18:45 Europe/Amsterdam, The Fallen Weeble
>wrote:
>
> > Whew... alright, this is what I propose (and I apologize because I
> > think
> > there have been a few too many proposals already, but...) is as
> > follows:
> >
> > 1. The basic process remains as is (select objects, select active,
> > issue
> > command, confirm).
> >
> > 2. The "Active" state is a subset of the "Selected" state.
> >
> > 3. Objects in the "Active" state should have a more distinguishing
> > color
> > (suggest white).
> >
> > 4. Parenting and tracking on single objects should return an error
> > since
> > it doesn't make logical sense (suggest "Error: must have more than one
> > object selected").
> >
> > 5. Confirmation dialog should have more clear language (suggest "Make
> > Active Object Parent" and "Track Active Object").
> >
> > Can we agree to use this as a starting point and go from there? Right
> > now we're doing a lot of needless running in circles and repeating
> > ourselves. Luke, while it remains to be seen whether or not your
> > confirmation/selection dialog would add or detract, I think it would be
> > a good idea to see how this works out. If it substantially clears up
> > the issue (as I think it will), then we're cool. If not, we can move
> > from there with other approaches such as yours.
> >
> > I apologize if I sound like I'm talking for the active developers, but
> > I
> > think this would be a feasible way to go and shouldn't be too difficult
> > to implement. I wouldn't mind trying, but I'm pretty sure someone more
> > familiar with the codebase could get it done faster. However, if
> > anyone
> > wants to send me an email, pointing me in the right direction, I'll see
> > if I can't do anything.
> >
> > Let's get this resolved and move on.
> >
> > Later.
> >
> > Groo
> >
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard@blender.org
> > http://www.blender.org/mailman/listinfo/bf-funboard
> >
> >
>------------------------------------------------------------------------
>--
>Ton Roosendaal Blender Foundation ton@blender.org
>http://www.blender.org
>
>
>--__--__--
>
>Message: 9
>From: "Clinton Baldridge" <funky_tit_sweat@hotmail.com>
>To: bf-funboard@blender.org
>Date: Sat, 27 Sep 2003 18:00:32 -0400
>Subject: [Bf-funboard] Re: Nvidia Cg Shaders
>Reply-To: bf-funboard@blender.org
>
>I am simply making a utility to test Cg shaders with in Blender, also it
>will export the GL code for the geometry of the Blender Object and the Cg
>programs initalization routines. The Idea is that since there is no game
>engine in Blender right now, this would at least allow people to test their
>Cg shaders in Blender and export the result. They could then manally put
>this code in whatever program they are making. I only brought it up here
>because I think realtime shaders are a great feature to have in Blender.
>The
>Python code that I am working on right now is basically the same as the
>GL/Cg code that would be nessasary to make this built in. The ability to
>use Cg shaders should be relativley easy to incorporate in any program
>drawing with OpenGL and I'm willing to work on it for whatever release of
>Blender. For right now though, I'm making this plug-in for the benifit of
>anyone who wants to use Blender to model objects for their game.
>
>Clinton
>
>p.s. This might be a stupid question. How do I post somthing like this
>Python Project on Blender.org? Sorry. I'm in my own little world.
>
>
> >From: bf-funboard-request@blender.org
> >Reply-To: bf-funboard@blender.org
> >To: bf-funboard@blender.org
> >Subject: Bf-funboard digest, Vol 1 #117 - 8 msgs
> >Date: Sat, 27 Sep 2003 15:58:01 +0200
> >
> >Send Bf-funboard mailing list submissions to
> > bf-funboard@blender.org
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> > http://www.blender.org/mailman/listinfo/bf-funboard
> >or, via email, send a message with subject or body 'help' to
> > bf-funboard-request@blender.org
> >
> >You can reach the person managing the list at
> > bf-funboard-admin@blender.org
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of Bf-funboard digest..."
> >
> >
> >Today's Topics:
> >
> > 1. (theeth/ton) Re: [Bf-funboard] Method 3 of reworking of ctrl-t,
> >ctrl-p, ctrl-c, etc.... (Luke Wenke)
> > 2. method 2b of reworking of ctrl-t, ctrl-p, ctrl-c, etc (Luke Wenke)
> > 3. Re: Nvidia Cg Shaders (Ton Roosendaal)
> > 4. workflow / reworking of ctrl-t, ctrl-p, ctrl-c, etc (Matt Ebb)
> > 5. Re: method 2b of reworking of ctrl-t, ctrl-p, ctrl-c, etc (Ton
> >Roosendaal)
> > 6. workflow / reworking of ctrl-t, ctrl-p, ctrl-c, etc (Luke Wenke)
> > 7. (ton) Re: [Bf-funboard] Method 3 of reworking of ctrl-t, ctrl-p,
> >ctrl-c, etc.... (Luke Wenke)
> > 8. Re: (ton) Nvidia Cg Shaders (Luke Wenke)
> >
> >-- __--__--
> >
> >Message: 1
> >From: "Luke Wenke" <lwenke@hotmail.com>
> >To: <bf-funboard@blender.org>
> >Subject: (theeth/ton) Re: [Bf-funboard] Method 3 of reworking of ctrl-t,
> >ctrl-p, ctrl-c, etc....
> >Date: Sat, 27 Sep 2003 17:51:51 +1000
> >Reply-To: bf-funboard@blender.org
> >
> >theeth wrote:
> >=====================
> >You'd still need Active object to determine what
> >object you are editing.
> >=====================
> >Ok, well I guess the "active object" system is there to stay...
> >
> >=====================
> > > This is partly incorrect. Try it yourself... create some meshes, then
> > > use "a" to select nothing, then use "b" to select some items. The last
> > > objectyou enclosed with the border will become active.
> >An object remains active when *not* selected... that's what you see
> >happening.
> >=====================
> >I get it now... it keeps a memory of which object was selected...
> >
> >=====================
> >I'm not happy with the way that visualizes, but you can see it at the
> >changed color of the 'centre point'.
> >=====================
> >Yeah, the unselected active thing has a pink dot in the center rather
>than
> >a
> >yellow one... I never knew what that meant before.
> >
> >=====================
> >'Active' and 'Selected' are important concepts, something we definitely
> >can look at improving to communicate. As mentioned in the UI makeover
> >doc, the UI doesn't stop with buttons and menus. This is an important
> >topic to work at as well. For our planning, I think it's more efficient
> >to do most that after 2.30 is out...
> >
> >=====================
> >For ctrl-T, etc it is about having one active object and one or more
> >selected non-active objects... it seems that it is irrelevant whether the
> >active object is selected or not... (using "a" and "b" you can make the
> >active thing unselected but have other things that are selected...) so
> >anyway, I never appreciated the significance of active objects really
>until
> >recently... I noticed that some selections were brighter than others, but
>I
> >didn't understand the exact significance of that. I think I worked out
>that
> >the bright one is the one you can edit (using tab) though...(even if it
>is
> >unselected and there are [non-active] selected things!)
> >
> >=====================
> >For example one segment/bar
> >with:
> >- title: Active Object
> >- items: "Make Parent of selected", "Copy attributes to selected", etc.
> >
> >=====================
> >I thought there was only one parent, and the active thing (even if it
>isn't
> >selected!) is the parent... so assuming that the active object is
>involved,
> >"Make Parent of selected" is a bad description since the parent-to-be
> >doesn't need to be selected! (It just has to be active)
> >So it could be "Create Parent from Active Object". (maybe active is a
> >deceptive word since it implies it is selected?) Also, saying "selected"
> >implies that one or more objects are the parent... but I think only one
> >object (the active one) can be the parent.
> >And maybe it should be "Copy attribute from Active Object". (it could be
>a
> >singular "attribute" since the ctrl-c menu only lets you select one
>object
> >at a time.) (It is implied that this attribute will be applied to the
> >selected objects)
> >
> >-- __--__--
> >
> >Message: 2
> >From: "Luke Wenke" <lwenke@hotmail.com>
> >To: <bf-funboard@blender.org>
> >Date: Sat, 27 Sep 2003 17:51:37 +1000
> >Subject: [Bf-funboard] method 2b of reworking of ctrl-t, ctrl-p, ctrl-c,
> >etc
> >Reply-To: bf-funboard@blender.org
> >
> >(see previous "Reworking of ctrl-t, ctrl-p, ctrl-c, etc" threads for
> >background info)
> >
> >1) select some objects
> >2) ctrl-p
> >3) The popup menu could say "Select Parent" and in the menu the list of
> >selected items is shown. If the active item wasn't initially selected,
>then
> >I'm not sure whether it should appear on the list... or maybe it could
> >appear, except be separated from the rest of the items. The mouse would
> >begin over the name of the active item. And when you move your mouse of
>the
> >various names, the objects could be tinted (just in case you can't
>remember
> >the name of what you want to be the parent) Then you left-click/enter or
> >press esc (like usual) to confirm or abort.
> >
> >The pop-up menu could look like this:
> >
> >(assuming the selection is object1 object2 active1)
> >Select Parent
> >==========
> >active1
> >----------
> >object1
> >object2
> >
> >And active could appear there whether it is selected or not (or maybe
> >that's
> >a bad idea because it implies that if you choose object1, it will be the
> >parent of active1 and object2) - on the other hand, the user should
> >probably
> >understand which things are the children since only the selected things
>can
> >be children (even though an unselected active object can be the parent)
> >
> >So anyway, this works as fast as the old method even if you have a good
> >understanding of how active things work...
> >
> >e.g.
> >using the new method (2b), applying ctrl-p and ctrl-t
> >1. select the items
> >2. select the active item if necessary (it isn't necessary with method 2b
> >since the active item can be chosen in the final step)
> >3. ctrl-p - mouse appears on active item
> >4. left-click to confirm - the name you clicked on becomes the new active
> >item
> >5. ctrl-t - mouse appears on active item
> >4. left-click to confirm - the name you clicked on becomes the new active
> >item
> >.
> >That is as fast as the current method... and if your desired active item
>is
> >hidden amongst lots of other items, method 2b is faster (in the current
> >method you've got to repeatedly do shift-RMB to search through the
>objects
> >-
> >in 2b, you can just pick the name from the final menu, and the objects
>can
> >be highlighted/tinted while you're browsing the list).
> >
> >- Luke.
> >
> >-- __--__--
> >
> >Message: 3
> >Date: Sat, 27 Sep 2003 12:24:50 +0200
> >Subject: Re: [Bf-funboard] Nvidia Cg Shaders
> >From: Ton Roosendaal <ton@blender.org>
> >To: bf-funboard@blender.org
> >Reply-To: bf-funboard@blender.org
> >
> >Hi,
> >
> >In my vision, the Blender 3 project is targeted at fully integrate with
> >programmable shaders, both for real-time as for 'traditional' rendering.
> >
> >I'd welcome experiments with it a lot... but I don't understand how
> >exactly the work you do fits in with Blender or engine now...?
> >
> >We should find a way to integrate this kind of work in our roadmap. My
> >preference would be to do that for the game engine project for after
> >2.3 is out (with Solid presumably!). There have been quite some
> >postings here and in the developers mailing list on how to organize the
> >game engine... a couple of coders are very interested in mainting and
> >improving that, including support for more advanced opengl shading.
> >With them we'll establish a new project & mailing list, to enable them
> >to work quite independent and with their own release cycle.
> >
> >Since this is a technical issue (as well), you might check on the
> >bf-committers mailing list for who to contact. :)
> >
> >The official release planning is still to get a 2.25 compatible open
> >source release out, before accepting changes/improvements in the engine
> >project. I really hope we can have this in 2.3.
> >
> >-Ton-
> >
> >
> >
> >On Saturday, Sep 27, 2003, at 02:08 Europe/Amsterdam, Clinton Baldridge
> >wrote:
> >
> > > Hi. I've started writing a Python program that will let you preveiw
> > > NVIDIA Cg vertex and fragment shaders in Blender. I should have a
> > > working version in a few days with support for basic Cg shaders. I'm
> > > going to make it possible to export OpenGL/Cg C code, so the object
> > > you've tried the shader on can be built into a game. When I have time
> > > I'll add more features and a gui to set shader and export values. I
> > > think it would be a lot better solution if it where a part of Blender
> > > though. How about this?: a Realtime Shader/Materials menu in
> > > Blender:-) Seems like a great Idea to me let me know what you think.
> > >
> > > Clinton
> > >
> > > _________________________________________________________________
> > > Instant message with integrated webcam using MSN Messenger 6.0. Try it
> > > now FREE! http://msnmessenger-download.com
> > >
> > > _______________________________________________
> > > Bf-funboard mailing list
> > > Bf-funboard@blender.org
> > > http://www.blender.org/mailman/listinfo/bf-funboard
> > >
> > >
> >------------------------------------------------------------------------
> >--
> >Ton Roosendaal Blender Foundation ton@blender.org
> >http://www.blender.org
> >
> >
> >-- __--__--
> >
> >Message: 4
> >From: "Matt Ebb" <matt@mke3.net>
> >To: <bf-funboard@blender.org>
> >Date: Sat, 27 Sep 2003 20:44:53 +1000
> >Subject: [Bf-funboard] workflow / reworking of ctrl-t, ctrl-p, ctrl-c,
>etc
> >Reply-To: bf-funboard@blender.org
> >
> >I think some of these discussions may be getting on to the wrong track a
> >bit, as some of the suggestions seem a bit un-blenderish to me. The
>Blender
> >workflow seems intuitive and visual, and I fear that choosing object
>names
> >from lists etc. is quite opposite to that Blender 'feeling'. When I'm
> >working I generally don't tend to name my objects (lazy perhaps?), but
>work
> >in the viewport. I remember something by the way it looks and it's
> >position,
> >not by a name.
> >
> >Although Luke's method may seem just as fast (same number of mouse
>clicks),
> >it wouldn't be in practise, as the more inconsistency means that the user
> >must spend more time remembering for a split second "oh I have to choose
> >the
> >selection *afterwards* for this command" rather than just doing it
> >naturally, the same was as everything else.
> >
> >Although it's not as consistent as it probably should be, to me, it seems
> >that most Blender tools work in a way like:
> >
> >1. Select something to operate on
> >2. Invoke command (via hotkey/toolbox/menu/whatever)
> >3. Optionally visualise or predict what will happen either interactively
> >(like move/rotate/scale) or non-interactively with a confirmation dialog
> >with an opportunity to cancel/undo the command
> >4. Confirm or cancel the command
> >
> >I think this sort of workflow is why Blender is quite usable without an
> >'undo' function. Rather than letting the user do things, mess up and undo
> >it, Blender often gives a way out before enacting the command in the
>first
> >place. It's like that Raskin UI theory of always giving people an exit or
>a
> >way to undo - Blender often does it, but more integrated with the
>workflow
> >rather than as a separate command.
> >
> >To be consistent with this, I like beatabix's suggestion:
> >1. Select the objects as usual, with one active
> >2. Invoke track command (via hotkey/toolbox/menu/whatever)
> >3. Display a confirmation along the lines of "Track selected to <active
> >object's name>" and at the same time, draw the helplines (perhaps
>partially
> >transparent?) from the selected objects to the active object so you can
> >visu
> >alise what will happen when you confirm the command.
> >4. Confirm or cancel the command.
> >
> >I absolutely agree that the selected/active distinction needs to be
> >visualised better. I have a few ideas on that which I need to think
>through
> >a bit too.
> >
> >Matt
> >
> >
> >-- __--__--
> >
> >Message: 5
> >Date: Sat, 27 Sep 2003 13:58:47 +0200
> >Subject: Re: [Bf-funboard] method 2b of reworking of ctrl-t, ctrl-p,
> >ctrl-c, etc
> >From: Ton Roosendaal <ton@blender.org>
> >To: bf-funboard@blender.org
> >Reply-To: bf-funboard@blender.org
> >
> >Hi Luke,
> >
> >I think you're looking in the wrong direction. We should separate the
> >two things as much as possible, to allow both new users as power users
> >to work with Blender.
> >
> >The issues are:
> >
> >1. Getting communicated as clear as possible what 'selected' and
> >'active' means for Blender. This is "context", as also described in the
> >UI doc
> >2. Make sure tools work in a consistant and non-blocking (nonmodal) way
> >with that.
> >
> >Using a popup menu which shows all selected objects is just wrong. This
> >is something a user already should (unconsciously) *know* at that time.
> >Including which Object actually is the single 'active' one.
> >
> >Quote:
> >"Where most of the users' time will be spent in routine operations of
> >the product and where learning is only a small part of the picture,
> >designing for productivity-- even if that requires retraining-- is
> >often the correct decision." [Raskin p 4]
> >
> >-Ton-
> >
> >(Not that I want to declare Raskin our Holy UI Saint! :P )
> >
> >
> >
> >On Saturday, Sep 27, 2003, at 09:51 Europe/Amsterdam, Luke Wenke wrote:
> >
> > > (see previous "Reworking of ctrl-t, ctrl-p, ctrl-c, etc" threads for
> > > background info)
> > >
> > > 1) select some objects
> > > 2) ctrl-p
> > > 3) The popup menu could say "Select Parent" and in the menu the list
>of
> > > selected items is shown. If the active item wasn't initially selected,
> > > then
> > > I'm not sure whether it should appear on the list... or maybe it could
> > > appear, except be separated from the rest of the items. The mouse
>would
> > > begin over the name of the active item. And when you move your mouse
> > > of the
> > > various names, the objects could be tinted (just in case you can't
> > > remember
> > > the name of what you want to be the parent) Then you left-click/enter
> > > or
> > > press esc (like usual) to confirm or abort.
> > >
> > > The pop-up menu could look like this:
> > >
> > > (assuming the selection is object1 object2 active1)
> > > Select Parent
> > > ==========
> > > active1
> > > ----------
> > > object1
> > > object2
> > >
> > > And active could appear there whether it is selected or not (or maybe
> > > that's
> > > a bad idea because it implies that if you choose object1, it will be
> > > the
> > > parent of active1 and object2) - on the other hand, the user should
> > > probably
> > > understand which things are the children since only the selected
> > > things can
> > > be children (even though an unselected active object can be the
>parent)
> > >
> > > So anyway, this works as fast as the old method even if you have a
>good
> > > understanding of how active things work...
> > >
> > > e.g.
> > > using the new method (2b), applying ctrl-p and ctrl-t
> > > 1. select the items
> > > 2. select the active item if necessary (it isn't necessary with method
> > > 2b
> > > since the active item can be chosen in the final step)
> > > 3. ctrl-p - mouse appears on active item
> > > 4. left-click to confirm - the name you clicked on becomes the new
> > > active
> > > item
> > > 5. ctrl-t - mouse appears on active item
> > > 4. left-click to confirm - the name you clicked on becomes the new
> > > active
> > > item
> > > .
> > > That is as fast as the current method... and if your desired active
> > > item is
> > > hidden amongst lots of other items, method 2b is faster (in the
>current
> > > method you've got to repeatedly do shift-RMB to search through the
> > > objects -
> > > in 2b, you can just pick the name from the final menu, and the objects
> > > can
> > > be highlighted/tinted while you're browsing the list).
> > >
> > > - Luke.
> > > _______________________________________________
> > > Bf-funboard mailing list
> > > Bf-funboard@blender.org
> > > http://www.blender.org/mailman/listinfo/bf-funboard
> > >
> > >
> >------------------------------------------------------------------------
> >--
> >Ton Roosendaal Blender Foundation ton@blender.org
> >http://www.blender.org
> >
> >
> >-- __--__--
> >
> >Message: 6
> >From: "Luke Wenke" <iljwamh1234567890@hotmail.com>
> >To: <bf-funboard@blender.org>
> >Subject: [Bf-funboard] workflow / reworking of ctrl-t, ctrl-p, ctrl-c,
>etc
> >Date: Sat, 27 Sep 2003 22:15:25 +1000
> >Reply-To: bf-funboard@blender.org
> >
> >Hi Matt,
> > > I think some of these discussions may be getting on to the wrong track
>a
> > > bit, as some of the suggestions seem a bit un-blenderish to me.
> >-----------------
> >I am exploring methods that are easier for beginners to understand while
>at
> >the same time are good for power-users. BTW, I've addressed many of the
> >problems you mention before... so I may sound like I'm repeating myself.
> >
> > > The Blender workflow seems intuitive and visual, and I fear that
> >choosing
> >object names
> > > from lists etc. is quite opposite to that Blender 'feeling'. When I'm
> > > working I generally don't tend to name my objects (lazy perhaps?), but
> >work
> > > in the viewport. I remember something by the way it looks and it's
> >position,
> > > not by a name.
> >-----------------
> >As I said, when you are hovering your mouse over the names of the items,
> >the
> >corresponding 3d object would be highlighted (perhaps in all available
> >views). You can move through the list quickly to see the objects
>highlight
> >and show themselves...
> >Or you can choose the active item like you normally do.
> >
> >This is how ctrl-T currently works:
> >1) select some things
> >2) make sure the right thing is active
> >3) ctrl-T
> >4) left-click without moving the mouse (or click elsewhere or esc to
> >cancel)
> >
> >And you can do exactly the same thing using my method!
> >Except that instead of the menu saying:
> >=========
> >*OK?* (bold)
> >Make Track
> >=========
> >
> >It would now say:
> >=========
> >*Track...* (bold)
> >active-item1
> >-----------
> >other-selected-item1
> >other-selected-item2
> >=========
> >
> >And instead of the mouse beginning over the word "Make Track", it will
> >appear over "active-item1" (or whatever the active item is called).
> >
> >And you can still cancel in exactly the same way to the old method. (esc
>or
> >move or click outside the menu)
> >
> >-----------------
> > > Although Luke's method may seem just as fast (same number of mouse
> >clicks),
> > > it wouldn't be in practise, as the more inconsistency means that the
> >user
> > > must spend more time remembering for a split second "oh I have to
>choose
> >the
> > > selection *afterwards* for this command" rather than just doing it
> > > naturally, the same was as everything else.
> >-----------------
> >If implemented, it should be done consistently involving all the relevant
> >functions of blender.
> >
> >BTW, I see g/r/s as being quite different - they only involve the
>selected
> >items, and if the active item isn't selected (it is possible to select
> >other
> >things while the active thing is unselected) then the active item is
> >ignored. On the other hand, ctrl-t, etc, always use the active item,
> >whether
> >it is selected or not.
> >The g/r/s functions only involve one group of objects.... ctrl-t, ctrl-p,
> >etc, use two groups of objects (the active item and the non-active
>selected
> >items). Also, there is no pop-up menu to confirm g/r/s like ctrl-t,
>etc...
> >so they are quite different in blender.
> >
> > > Although it's not as consistent as it probably should be, to me, it
> >seems
> > > that most Blender tools work in a way like:
> > >
> > > 1. Select something to operate on
> > > 2. Invoke command (via hotkey/toolbox/menu/whatever)
> > > 3. Optionally visualise or predict what will happen either
>interactively
> > > (like move/rotate/scale) or non-interactively with a confirmation
>dialog
> > > with an opportunity to cancel/undo the command
> > > 4. Confirm or cancel the command
> >======================
> >My idea has those steps, except that the active item can be changed in
> >steps
> >3 and 4 (by moving the mouse before you click or press enter). And as
>said
> >earlier you can still just select the active item in step 1 or cancel the
> >operation after you've press ctrl-T (using esc, etc).
> >
> > > I think this sort of workflow is why Blender is quite usable without
>an
> > > 'undo' function. Rather than letting the user do things, mess up and
> >undo
> > > it, Blender often gives a way out before enacting the command in the
> >first
> > > place. It's like that Raskin UI theory of always giving people an exit
> >or
> >a
> > > way to undo - Blender often does it, but more integrated with the
> >workflow
> > > rather than as a separate command.
> >-----------------
> >As said earlier, that is part of my idea.
> >
> > > To be consistent with this, I like beatabix's suggestion:
> > > 1. Select the objects as usual, with one active
> > > 2. Invoke track command (via hotkey/toolbox/menu/whatever)
> > > 3. Display a confirmation along the lines of "Track selected to
><active
> > > object's name>" and at the same time, draw the helplines (perhaps
> >partially
> > > transparent?) from the selected objects to the active object so you
>can
> >visu
> > > alise what will happen when you confirm the command.
> > > 4. Confirm or cancel the command.
> >-----------------
> >My idea is virtually identical to that except step 3 isn't ambiguous. You
> >aren't actually Tracking the selected items to <active item>.... you are
> >only tracking the selected non-active items to the active item.
> >
> >My popup menu would look like this (with the mouse beginning on the the
> >active object's name):
> >*Track....* (bold - since it is a key word)
> ><active item> <-(mouse pointer starts here)
> >------------
> ><other selected item 1>
> ><other selected item 2>
> ><other selected item 3>
> >
> >While their mouse is hovering over active item's name, the "helplines"
>you
> >describe in (3) could be drawn.
> >
> >Then you left click on <active item> (it's name in the menu, where the
> >mouse
> >already is) to confirm. (or press esc - or select something else, while
>at
> >the same time the objects change to reflect which one is the new active
> >object)
> >
> >-- __--__--
> >
> >Message: 7
> >From: "Luke Wenke" <iljwamh1234567890@hotmail.com>
> >To: <bf-funboard@blender.org>
> >Subject: (ton) Re: [Bf-funboard] Method 3 of reworking of ctrl-t, ctrl-p,
> >ctrl-c, etc....
> >Date: Sat, 27 Sep 2003 23:30:32 +1000
> >Reply-To: bf-funboard@blender.org
> >
> >Hi Luke,
> >--------------------------------
> > > 1. Getting communicated as clear as possible what 'selected' and
> > > 'active' means for Blender. This is "context", as also described in
>the
> > > UI doc
> >--------------------------------
> >Actually there are 3 categories of things that the commands work on...
> >1. selected non-active items
> >2. selected active item
> >3. non-selected active item
> >
> >g, r, s, etc, treat all selected items (1 and 2) the same...
> >ctrl-t, ctrl-p, ctrl-c, etc, treat the active item (2 or 3) the same
> >whether
> >it is selected or not. and group the other selected items together.
> >
> > > 1. Getting communicated as clear as possible what 'selected' and
> > > 'active' means for Blender. This is "context", as also described in
>the
> > > UI doc
> >-----------------------------------
> >What if the active item was more distinct from the other selected items?
>It
> >could be red and the others are blue. It is metaphorical I think
>(something
> >you might want)... the single red object represents something that is
> >aggressive - that is the centre of attention. The blue objects are the
> >passive crowd. When you use ctrl-T, the blue it around and watching the
>red
> >thing move (the red thing is the centre of attention). If you use ctrl-P,
> >the red thing is the leader (the parent) the others are the shy
>followers.
> >For ctrl-C, the red thing is the source of something, the blue things are
> >the passive receivers of it. (Many blue things can copy its attributes,
>so
> >it again is the focus of their attention)
> >
> >So what do you think of red for the active object and blue for the other
> >selected items? I think it would be easier for a person to learn about
>than
> >bright pink and darker pink. Partly because of the big contrast in
>colours,
> >so they'd soon pick up that the last think you select becomes the red
> >thing,
> >and that there is always only one active thing. Also, when things aren't
> >selected, they could have a white or grey centre, and the actie thing
>could
> >have a red centre. (The non-active non-selected things could have a
> >colourless centre so that the active non-selected thing stands out more)
>If
> >the active item is unselected and there are some selected items,
>currently
> >in blender the user probably wouldn't notice that... but if there was red
> >and blue they would... they'd notice that the big red object is gone...
> >they
> >might think - why are all the objects blue? Why isn't there a red thing?
> >Then they might see that rather than being gray, one of the unselected
> >object centres is red... "there it is"... so when they use ctrl-T, etc,
>it
> >would be easier for them to know where the active object is - if it isn't
> >selected.
> >
> >I remember that in posemode, bones are light blue and cyan.... maybe they
> >could be made a bit more greenish or purplish in order to distinguish
>them
> >from the blue idea I had, but it is still similar to the old colours so
> >that
> >it doesn't come as such a shock to old users..Or the non-active
>selections
> >could be blueish-green or blueish-purple rather than blue, so that the
> >pose-mode colours can stay the same. (If it is pure green, those with
> >colour
> >blindness might be able to distinguish it from the red)
> >
> >BTW, (to change the topic) here is a suggestion that is similar to
> >beatabix's....
> >
> >The pop-up menu could say:
> >
> >Track <active-object-name>?
> >OK
> >
> >So there is a fairly good English sentence and you can reply to it. I
>don't
> >think it is necessary to draw other stuff on the screen - having the
> >objects
> >in red and blue should be clear enough. (where red is the focus/source -
> >which is quite intuitive)
> >
> >At the moment the menu is:
> >OK?
> >Make Track
> >
> >That isn't really English... people might think "what's a track?" But
>when
> >you say "Track xxxx" it is fairly clear that track/tracking is a verb.
>BTW,
> >you will let you "Make Track" even if nothing is selected... the user
>might
> >say "so where is this track I made?" Maybe the pop-up menu shouldn't even
> >appear if not enough things are selected - or there could be a helpful
> >error
> >message.
> >
> >.- Luke.
> >
> >-- __--__--
> >
> >Message: 8
> >From: "Luke Wenke" <iljwamh1234567890@hotmail.com>
> >To: <bf-funboard@blender.org>
> >Date: Sat, 27 Sep 2003 23:55:52 +1000
> >Subject: [Bf-funboard] Re: (ton) Nvidia Cg Shaders
> >Reply-To: bf-funboard@blender.org
> >
> >ton wrote:
> >=====================================
> >In my vision, the Blender 3 project is targeted at fully integrate with
> >programmable shaders, both for real-time as for 'traditional' rendering.
> >=====================================
> >
> >That would be awesome! I think in theory, the Nvidia cards should be able
> >to
> >support practically everything, like environmental maps, motionblur
>(using
> >an accumulation buffer, or "FSAA"), high-res shadow maps, particles,
>blinn
> >and maybe other Blender shaders, etc...
> >
> >It would be good if the output of Nvidia cards could look identical to
> >blender's rendered output (apparently they can use 128-bit floating point
> >colours or something, etc)... that would mean huge performance
>improvements
> >in Blender's rendering times. I mean new video cards will be able to
>render
> >Doom 3 at about 30+ frames per second, and that includes totally dynamic
> >lighting, bump-mapping everywhere, specular highlights, tricubic texture
> >filtering, etc, at a high resolution. Yet using blender it would take at
> >least about 10 or 20 seconds to render one frame of that. Of course, the
> >meshes in 3d games look fairly chunky up close, but you could simply give
> >the 3d card a more complex model - and it would take longer to render it.
> >(Rendering could be sped up a bit by using hardware T&L)
> >Currently in blender there is an icon for rendering things using
>openGL...
> >you can even render animations in it (by also holding shift)...
> >
> >BTW, maybe the Nvidia cards can do wide camera angles properly (I think
>the
> >software version of quake had this)... it makes polygons curve, which is
> >cool. I think the only way you can do that in blender is to use
>"Panorama".
> >
> >- Luke.
> >
> >
> >-- __--__--
> >
> >_______________________________________________
> >Bf-funboard mailing list
> >Bf-funboard@blender.org
> >http://www.blender.org/mailman/listinfo/bf-funboard
> >
> >
> >End of Bf-funboard Digest
>
>_________________________________________________________________
>
>
>
>
>--__--__--
>
>_______________________________________________
>Bf-funboard mailing list
>Bf-funboard@blender.org
>http://www.blender.org/mailman/listinfo/bf-funboard
>
>
>End of Bf-funboard Digest
_________________________________________________________________
Instant message in style with MSN Messenger 6.0. Download it now FREE!
http://msnmessenger-download.com