[Bf-funboard] Policy
bf-funboard@blender.org
bf-funboard@blender.org
Mon, 16 Jun 2003 01:01:40 -0600
<TT><pre><BR>
1. EASY TO DO!<BR>
<BR>
-- Right-mouse select, replace with context driven menus?<BR>
We can think over a new organization of default mousebutton <BR>
behaviour. <BR>
Contextual menus can be a great aid in learning and using Blender.<BR>
<BR>
<b><BR>
Consider this, when doing context sensitive popup menu check <BR>
the view to see what functions are available there, if in a mode <BR>
check to see what functions are available in the mode, if object is <BR>
selected check to see what functions can operate on object, <BR>
if over a set of unselected objects give the option to select <BR>
the desired object by name, if over a widget offer to input a <BR>
value.. But if multiple things are possible, multiple menus are <BR>
possible, or say the mouse is above multiple objects you have the <BR>
option to select any of the objects by name from the popup menu. <BR>
</b><BR>
<BR>
-- Gestures: Maya style hotbox?<BR>
Also called 'pie menu'. It can just be something to replace current <BR>
SPACEBAR menu.<BR>
<BR>
<b><BR>
I'd avoid following Maya's lead on the part about hotbox, its <BR>
nice but it can overcomplicate working as its an extension of the <BR>
multiple sub-menus per sub-menu concept that just confuses users no <BR>
end.. It should be possible, but not standard.. I think the <BR>
advantage of blender is its not bloated like Maya.. Could develop a <BR>
concept of layered hot-keys for power users... Like a hotkey-tree.. <BR>
Like translate move might be space+t+m, then the power user will <BR>
rationalize the hotkey combination as words and call them up like <BR>
typing words on the keyboard.. Of course the power user could <BR>
reconfigure the order of the hot-key tree, and with each hotkey a <BR>
popup-menu is evoked, if the user is quick enough the popup menus <BR>
are never shown. As sound could be attributed with the function <BR>
requested to allow canceling of the function if its the wrong one, <BR>
or maybe there could be a safety mode where actions are delayed a <BR>
little time (user settable) when the user can cancel the action.<BR>
</b><BR>
<BR>
<BR>
-- Wireframe colors<BR>
We can review how it currently works in Blender, and come with a <BR>
proposal how it gives a bit more control and visual feedback. This <BR>
should also include thinking over how 'solid drawing' will be <BR>
handled.<BR>
<BR>
<b><BR>
I think there should be a concept called a "view filter" or "select <BR>
filter", that is you can cutomize the filter to color the wireframes <BR>
according to your preferences, it would be like holding shift down <BR>
or some such key switches to view filter mode temporarily <BR>
and allows you to see the various kinds of objects, then you <BR>
depress the key and it returns to normal.. Same with a selection <BR>
filter, you switch temporarily to a mode for selecting only a <BR>
particular type of object, click on the object and depress <BR>
the key that went into the select filter.. The filters could be <BR>
configurable at the top of the interface or in a popup menu.. <BR>
<BR>
The select filter would reuse the view filter to customize coloring <BR>
to ghost objects that are not selectable.. But the advantage of <BR>
being able to toggle a selection filter is that you have <BR>
the advantage of being able to select any object, hold down a key <BR>
and select a specific kind of object, depress the key and perform <BR>
an operation.. Also custom filters could be established by <BR>
selecting some objects and adding them or removing them from the <BR>
filter.. <BR>
<BR>
Solid drawing in a view filter mode looks as wireframes do, this <BR>
would be expected.. <BR>
</b><BR>
<BR>
<BR>
2. MEDIUM COMPLEX<BR>
<BR>
-- Manipulator (handles) for transform<BR>
As an aid to vizualize selection status and rotation/scale values, <BR>
a <BR>
manipator can be drawn which of course allows scaling/rotating as <BR>
well.<BR>
(maya: http://www.highend3d.com/maya/tutorials/subdiv/image3.jpg)<BR>
<BR>
<b><BR>
Great for beginners bad for powerusers.. I think the <BR>
combination drag+MMB option for constrained scale/translate <BR>
according to closest axis plane is the best. Its a feature, frankly, <BR>
I wish Maya had.. I think the only thing blender is missing is a <BR>
capability of moving transformation mode's pivot to get precise <BR>
rotation, but blender's target cursor subtitutes for this <BR>
pretty well.. Also I'm sure other transformation tricks that <BR>
Maya implements could be done as user-defined transformations for <BR>
which the mouse movements could control say a parameter in a <BR>
function that controls the transformation of the object.. <BR>
<BR>
I have a plan for a user-defined functionality concept where <BR>
users can create custom button panels, could be grouped with <BR>
user-defined 3D widgets, primitives.. But not sure how to approach <BR>
the concept.. I could imagine that this could be extended to <BR>
add manipulation modes to existing primitives in blender, so <BR>
that the manipulator that implements scale, move, rotation <BR>
could be like a complex blender type that could be stored in a <BR>
blend file or a partial blend file and distributed like a plugin. <BR>
The users would be allowed to customize the manipulators however <BR>
they wish, by associating constrained movements of widgets with <BR>
primtives. The look & feel of the widgets could be defined with <BR>
python.. Selection/Control of widgets would be like that of an <BR>
object, select the control, move it.. The widgets would only appear <BR>
when the object is selected and when in a special manipulator-view-<BR>
on mode. Any objects could have widgets, a choice of the users, <BR>
like there could be normal-to-polygon translate-move of polygon <BR>
manipulation mode.. Of course the manipulators should also <BR>
have hot-key/gesture versions, that are user configurable. <BR>
<BR>
The addition of user-defineable manipulators will allow custom <BR>
programming of manipulators to allow for grab-pinch and haptive <BR>
feedback devices to be used.. And hand gestures to be used to <BR>
control hte particular feature needed. <BR>
</b><BR>
<BR>
<BR>
-- External Render integration<BR>
With the impressive improvements in Yafray, we should start with <BR>
them a <BR>
project how a good collaboration (interface) with their render <BR>
system <BR>
can be achieved. Same applies for 3Delight or Renderman of course.<BR>
<BR>
<b><BR>
User defineable panels (with bound python scripts or <BR>
possibly a executable plugin) that bind to the rendering interface, <BR>
can be seperately updated and maintained from blender. <BR>
<BR>
Panels could have widgets that can be used to define things <BR>
specific to the renderer in the 3D view.. Also the addition <BR>
of panels in the rendering system to control the materials, <BR>
optionally augment or replace the preview window with <BR>
material renderings specific to the render.. The preview <BR>
mode plugin could be a local executable or a call to the renderer, <BR>
either as its running (server interface to the <BR>
renderer, possibly with verse) or as a call-as-needed script <BR>
execution.. The call as needed scripts may need their own <BR>
configuration which could be maintained as a associated <BR>
configuration type (for setting things like path directories to <BR>
renderers, flags, etc.). The configurations are stored with the <BR>
blend file. <BR>
<BR>
When updating a slider of a material/render plugin, events are <BR>
sent to the plugins handlers to update the preview window if <BR>
visible. <BR>
<BR>
Each plugin would have a option to provide help, in such cases the <BR>
help gets added to help system to search for manual <BR>
information on specific plugins, the user should have the option <BR>
to annotate and add to the manual as needed, to leave notes for <BR>
themselves, help doc annotation is stored seperate from <BR>
documentation but associates with the plugin documentation, by way <BR>
of referencing the plugin, so that if the help manual changes the <BR>
annotations are not lost.. <BR>
</b><BR>
<BR>
<BR>
--- Buttons & headers, better user configurable organisation<BR>
Like some menus that pop up now (NKEY) we can make them become <BR>
persistant and movable. This will allow users to add menus/buttons <BR>
to <BR>
each window in Blender. Think for exampe of Ipo settings, View3d <BR>
settings, NLA window buttons, etc. The same structure can be <BR>
appplied <BR>
to the ButtonsWindow itself, grouping them in 'blocks' and let the <BR>
user <BR>
arrange or collapse them.<BR>
<BR>
<b><BR>
Sounds like a user defineable panel concept.. But not sure how <BR>
its like or different.. <BR>
</b><BR>
<BR>
<BR>
Additional to that, the headers system can be extended to a <BR>
verticial <BR>
user-configurable one. The horizontal then remains 'standard'.<BR>
(old sketch: http://www.blender.org/bf/_shop_/bi5.jpg)<BR>
<BR>
<b><BR>
Well I think it would be good to have a panic button that returns <BR>
blender temporarily to a default configuration, which would <BR>
be what everyone is familiar with.. But users should be able to <BR>
configure their interface how they want.. In the idea I had for user-<BR>
defineable panels, I think that there will be a similarity in how <BR>
users can configure buttons and panels and the way a plugin can <BR>
can, the difference is the plugin is a low level implementation <BR>
and the user configuration could alternately be just a configuration <BR>
or a self-contained plugin (albeit not written in C++ or C, but <BR>
python).<BR>
</b><BR>
<BR>
<BR>
-- Constraints: replacing parenting and tracking<BR>
Is part of the paper of Reevan on character animation. It can be <BR>
implemented transparant (CTRL+P adds parent-constraint) but allows <BR>
for <BR>
very interesting new features, such as animatable multiple parents, <BR>
Z-axis constraints, python constraints, etc.<BR>
<BR>
<b><BR>
A play on the idea of user-defineable manipulators. <BR>
This is related to how Maya can control objects with expressions, <BR>
but I think expressions could be combined with existing input <BR>
to create a concept of a passthru parameter and weighting.. So <BR>
that you could say give the movement of a object 30% translation <BR>
by a path, and 70% translation by a pivot. <BR>
</b><BR>
<BR>
3. HARD WORK:<BR>
<BR>
-- Python integration in main event loop, configurable hotkeys and <BR>
tools<BR>
This is a technical one... but the integration with Ghost was only <BR>
finished half. The goal can be rebuilding the internal events <BR>
structure <BR>
to allow Python hooks, configurable hotkeys, and of course Macro's! <BR>
(I <BR>
don't even mention undo :-)<BR>
<BR>
<b><BR>
Are hotkeys events implemented as events or are they <BR>
implemented polling structure like <BR>
if key is "x" do delete <BR>
if key is "g" do grab <BR>
<BR>
etc.. <BR>
If we could have an event handler and allow dynamic <BR>
addition and removal of event handlers, then there would <BR>
only need to be a minimal amount of code in the main loop, <BR>
that just captures key events and mouse events, <BR>
and places the events on a queue to be handled by a dynamic set <BR>
of event handlers.. The event handler could then filter out <BR>
events based upon a mode event filter, like if you were in <BR>
and edit mode, you should be able to call object move <BR>
and translate functions, only vertex move and translate ones.. <BR>
<BR>
The purpose for having the event queue for hotkeys/mouse events, <BR>
is we could add other kinds of controllers, pens, haptive feedback, <BR>
motion suits, etc.. It also reduces the clutter in the main <BR>
interface.. In most cases the events will be responded to as they <BR>
would if being checked for in the main loop.<BR>
</b><BR>
<BR>
-- New Mesh editor<BR>
Learning from Nendo or Wings... we really should upgrade this <BR>
modeling <BR>
system in Blender. Should be done in close cooperation with the <BR>
coders <BR>
however... but they *do* need feedback!<BR>
<BR>
<b><BR>
If we could determine a common denominator for polygons, <BR>
we could define wings as a specialization of the common denominator <BR>
polygon type.. So that wings may be a different primitive but <BR>
it inherits the functionality that allows us to model non-wings <BR>
polys.. It would be better to determine how different it would <BR>
be to implement wings and also to see if there is a super-set of <BR>
blenders polys and wings so that functionality can be shared between <BR>
them and future primitives that reuse wings or blender's polys <BR>
will inherit the functionality that is common to both. wings and <BR>
blender's polys.. It shouldn't be the case that we have <BR>
either blender polys or wings, if we can find a common <BR>
generalization or parent from which the two inherit similarities, <BR>
we could support both without having to support code for two <BR>
different kinds of primitives.<BR>
<BR>
I strongly suggest using a class-diagram to determine the "schema" <BR>
of the Winged edges scheme and of blender's curent scheme and <BR>
possibly determine the better scheme that covers both as much as <BR>
possible... If the schemas are too different, we could translate <BR>
from one to the other in the case of a "conversion". <BR>
</b><BR>
<BR>
<BR>
-- Decision on Game Engine & players<BR>
Although I really *love* the concept of a fully integrated 3d <BR>
suite, <BR>
the game engine in Blender brings a load of complex issues:<BR>
- it doesn't integrate too well (code is nicely separated, works <BR>
fine <BR>
for coders, but limits its functionality)<BR>
<BR>
<b><BR>
Game Blender is written in C++ , Blender is written in C.. <BR>
I think over time Game Blender could be a part of blender when <BR>
Blender is upgraded to C++.. Blender at the very least should <BR>
move to C++.. <BR>
<BR>
Game Blender is essentially a plugin into blender, it brings its own <BR>
panels, 3D widgets possibly, hotkey handlers, input handlers, <BR>
interrupts, etc.. I think Game Blender if treated like a plugin <BR>
could help to define what is needed in the plugin interface.. <BR>
(below I change my mind)<BR>
<BR>
The other concept is a Verse style relationship, but Verse doesn't <BR>
allow modules to call adjacent client modules. <BR>
<BR>
Example of allowing plugins to call plugins, You could say have game <BR>
blender record object IPO's by way of API's to functions, data and <BR>
access to other plugins. Plugins cannot own a feature as that could <BR>
create deadlock/busy-state problems, so there will have to be an <BR>
issue of precedence or order of control.. Like GameBlender plugin <BR>
may be writing to an IPO that is defined by an expression. In such <BR>
cases blender could alert the user "IPO is not writeable". <BR>
Or something more userfriendly. Thus every data object in blender <BR>
will be called a resource, and resources can only be bound once, <BR>
but the function (possibly an object) that binds to them could <BR>
offer up one or multiple inputs to allow pass-thru control, so <BR>
that there could be a way to write an expression where <BR>
GameBlender could write to the IPO without getting a "IPO is not <BR>
writeable" message.. The only problem in such a case is that <BR>
it would not be possible to read back what game blender wrote <BR>
out in the same form, but that's not important, or even possible, <BR>
unless we write to say an IPO that is being used as input <BR>
into a mixer-node that writes to an IPO. <BR>
<BR>
Execution would need to be handled by executing the top-most <BR>
node on the sub-nodes, and recursively down to the object node.. <BR>
Circular dependencies could be determined by using a stack (maybe) <BR>
or leaving behind bread-crumbs (flags). <BR>
</b><BR>
<BR>
- If you check the old NaN bug tracker, you'll find 80% of the <BR>
reported <BR>
bugs is in the Game engine, or its lack of integration with Blender.<BR>
<BR>
<b><BR>
Is this due to Blender being written in C and game blender written <BR>
in C++?? Or is it that blender doesn't share any features with <BR>
game blender.. If the integration is really bad, we could split <BR>
game blender as you suggest from blender, until blender is more <BR>
capable of being merged, possibly working game blender until it <BR>
uses much of the same code blender uses..<BR>
</b><BR>
<BR>
- the Web plug-in player is a HELL of a project to build & maintain.<BR>
<BR>
<BR>
<b><BR>
Thus bringing about the concept, why not make blender the browser <BR>
and saying to Mozilla/Netscape/IE "Forget you"... I really believe <BR>
blender could become its own environment.. Also another possibility <BR>
is to abstract the basics out of what Netscape/Mozilla/IE require <BR>
and make blender's plugin a generalization of the the specialization <BR>
of all those plugins.. Allow developers that are interested in <BR>
keeping the plugin compatible on each platform to customize the <BR>
interfaces, but to keep GameBlender plugin from being tightly <BR>
bound to the browser's API. <BR>
</b><BR>
<BR>
It will make the current projects a lot easier if we can decide to <BR>
split off the game engine. It can be done in 2 steps:<BR>
1. stand-alone game player, which receives signal from Blender to <BR>
read <BR>
the 3d data and start play<BR>
2. moving the game logic and game-editing tools to a new editor.<BR>
<BR>
<b><BR>
I think number 1 would be better than 2.. Until blender's <BR>
internals are suitable for merging in as number 2. 1 would be <BR>
more inline with the way that blender was designed to be <BR>
used with Playstation test systems (a friend of mine who had worked <BR>
for Sony for a couple of years called these systems "cutters", if <BR>
that means anything). <BR>
<BR>
There is very little that the two would have in common, and <BR>
blender may become less optimal as a game engine as it focuses on <BR>
providing high-level functionality and game engine searches for <BR>
optimal essential low-level functionality. It seems like they <BR>
would be going in different directions, and Blender's level <BR>
of indirection would get complicated with game blender's level of <BR>
optimization. But the two may share a common core for handling <BR>
input events and button panels, navigation, basic manipulations, <BR>
plugin interfaces, etc.. <BR>
</b><BR>
<BR>
<BR>
Once the the Solid library is back, we can review how coders pick <BR>
the <BR>
engine up. We then have several choices:<BR>
<BR>
- bring it back to Blender<BR>
- just work on good export facilities to other engines as well.<BR>
- put back the old (2.04) engine, and keep that simple and limited, <BR>
for <BR>
interactive testing and prototyping only.<BR>
<BR>
<b><BR>
Is Solid the rigid body dynamics system? Or is having to do with <BR>
booleans? I think rogid body dynamics in blender would be useful <BR>
if it could be used to cook IPO's. But this is something that will <BR>
likely be shared between game blender and blender. Note that <BR>
rigid body dynamics could be considered to be like expressions <BR>
that control objects, its questionable how keyframed objects <BR>
would interact with realtime simulations.. <BR>
</b><BR>
<BR>
<BR>
This is a complex issue, and is worth putting a workgroup together <BR>
for <BR>
it.<BR>
<BR>
-Ton-<BR>
<BR>
<font color=red><BR>
---------------------------------------------------------------------<BR>
--- <BR>
--<BR>
Ton Roosendaal Blender Foundation ton@blender.org <BR>
http://www.blender.org<BR>
<BR>
_______________________________________________<BR>
Bf-funboard mailing list<BR>
Bf-funboard@blender.org<BR>
http://www.blender.org/mailman/listinfo/bf-funboard<BR>
<BR>
<BR>
---- End Original Message ----<BR>
<BR>
</pre><BR>
<BR>
</TT><br><br><br><br><br><br><font><p align=left><br><TT>Sign up today for your Free E-mail at: http://www.canoe.ca/CanoeMail </TT>