[Bf-funboard] Re: Nvidia Cg Shaders

[Clinton Baldridge]

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

_________________________________________________________________