[Bf-funboard] more jobs

[Daniel Fairhead]

> - Better 'mode' feedback
> Editmode, VertexPaint, FaceSelect and the like are blocking modes. This  
> is actually violating general UI design rules...  new users have  
> problems with it.
> We can't easily get rid of it, but it can be better communicated:
>    - new cursortypes (all platforms! we need a designer for it)
>    - the associated icon drawn in the corner of the window, maybe with a  
> nice shaded backdrop.
> More ideas can be evaluated.

My Possible Solutions:

(a) next to the left-bottom axis indicator in the 3dview, have a small 
text thing with "Edit Mode (TABKEY)", "VertexPaint Mode(V)" etc on it.

(b) A new window-type called "Toolbar" or something similar, which
contained a set of larger (30x30? ala webbrowser) iconic/text buttons,
with the different modes, or such in. This is actually something I think
might be useful in many ways, some new window-types, for many of the 
features people are asking about. It should be fairly simple (compared to
say, a ray-tracer, :-) ) to add two new window types, one for a toolbar,
and another for context-menus, like the left-side menu in Moonlight, or
other ones similar.

(c) Different coloured backgrounds for different modes. I don't like this
idea much, as it could distort ones eye white-levels, or whatever, ending
up with over-red balanced images, or whatever.

(d) Coloured borders on windows in edit-mode.

(d) on the buttons-bar (typically below the 3dwindow) when you switch
into edit-mode, you get some difference in buttons displayed. It should
not be too hard to have an "Edit Mode" label added to the buttons-bar.

> - Particle system deflectors / attractors
> Just simple force field generators. Fun!

As a new "pop-up" (like "edge settings" in render) in the "edit buttons"?

> - Integrate most used texture & sequence plugins in Blender
> (voronoi, musgrave, zblur)

I'd disagree here. I think that it would be better for the plugins-system
not to have more and more built-in to blender, but for blenders plugin
system to be easier for plugins to "join in" to. For instance, if instead of
having "Plugin" as one of the options in material, All texture plugins in the 
texture-plugins-directory were either loaded along-side the built-in ones,
or were "registered" into the list, so they could be loaded when needed.
A Pup-Menu might be nice to replace the current horizontal list with, btw.

I'd actually vote to have all currently built in texture & sequence types
removed from the blender-base, and compiled as plugins, and auto-loaded.

Then I could remove from the list the ones I never use (noise) and add plugins
I do use to the list, (clouds2), etc.

> - An 'about' menu item, giving splash and a nice listing with credits  
> for people who contributed

*grins* this could get big...

> - add 'Properties' to all main blocks in Blender
> Both at UI as Python level. The Property system now only is used for  
> the game engine.
> This way a user can extend a Material with extra properties for export  
> to Renderman for example. Or to control a python script with, and have  
> it all nicely stored in the .blend.

Sounds cool!

> - remove the current game engine, into a separate tool
> A *really* touch one to decide, since I am the biggest supporter of a  
> fully integrated tool. However, there are technical reasons to do it;  
> nobody codes in the engine, it doesnt work yet, it is not well  
> integrated with Blender.
> This also can help getting support for other engines working better.  
> Plus, we can still keep a simple engine to at least be able to do  
> walkthroughs, character animation tests, and the like.

Could we perhaps have two executables, using the same code, which
were basically the same, but the "art" one would not have the extra 
game buttons/windows, and the "game" one would not have the extra
"art"/"rendering" buttons/windows? Or is this just silly?


> Well, this board is there for difficult decisions too! Who mentioned  
> raytracing? :)

In a way... isn't this less of a "hard" decision...  I mean, all it needs is
for someone, or some team of people to say "I believe I can write a
ray-tracer of some variety into blender either without removing the
current one, like the unified renderer, or by making it selective within 
one of the current ones" and then to go an do it?

The only hard bit is finding someone willing and capable to do it...

Dan