「Dev:2.8/Source/Workflow/101 Roadmap」の版間の差分

提供: wiki
移動先: 案内検索
(Tasks: manipulators)
 
(1版 をインポートしました)
 
(相違点なし)

2018年6月29日 (金) 06:23時点における最新版

Blender 101 planning

  • Project to make 101 template (working, on a basic level)
  • Manipulators (working, on a basic level)
  • Tool system (work in progress, see: T53047)
  • Upgrade notifiers (TODO: design task)

Tasks: templates

  • Define a use case proof of concept [need designer?]
  • Create manipulators for this use case

Tasks: manipulators

Note, a lot of these tasks are to tie up loose ends.

  • Final design for cage 2d and 3d [design team?]
  • Upgrade notifiers (replace hard coded ID's with generic notifier type)
  • Integration with snap system
  • Integration with draw manager (at least for anti-alias) [questionable priority]
  • Define rule for when a manipulator is visible [design team?]
  • Define bare-minimum manipulators to a complete use case (e.g., 101) - [design team?]
  • Documentation on how to make more manipulators (code documentation)
  • Face maps (real-world test existing add-on, have riggers use them to define their own).

Tasks: tool system

  • Design:
    • Overall design for the tool system, proposal made.
    • Define which tools should be supported as active tools.
    • Define which tools should have manipulators associated with them.
  • Implement tool-system with 2-3 example tools for review & approval for 2.8 branch.
  • Integration with top bar.
  • Implement remaining tools we agree make sense in the tool-system.
    • Tweak operators to work in the tool-system.
    • Create custom manipulators.

Detailed tasks:

  • Manipulators - Face maps
Need real world testing. Next BI project to use it for new characters.
That means (1) this is one of the priorities once the project starts, and (2) we need depsgraph for basic rig to not crash Blender (even if it requires custom build flags).
Right now advanced widget shapes is possible with primitives. We will see if that’s enough.
  • Manipulators - Documentation on how to make more manipulators
Manipulators is an on-going task. So it’s important to allow other developers to implement their own manipulators.
  • Manipulators - Define rule for when a manipulator is visible
If you have many possible manipulators, how to choose which ones are shown?
We need to define design rules for the manipulator visibility.
A few options:
    • Ever manipulator can be controlled from a menu in each space: View →Manipulators.
    • Manipulator option controls all manipulators so you see all or nothing.
    • Always show, be very careful not to make them annoying. (e.g, render border)
    • Manipulators need to be activated, they won’t show automatically when you select (don’t like - just an example).
  • Define which tools should be supported as active.
    • We implement bare minimum set of tools, then re-evaluate (akin to the manipulators process).
    • What we need to make sure is that users have a clear picture on which operators are tools and which ones are not.
    • We can do that by having them in their own panel, a new category, a ui-box or similar.
    • Implement remaining tools we agree make sense in the tool-system
    • Operators will need to be tweaked to work in the tool-system in many cases. In some cases a significant amount of time will be creating custom manipulators.
    • This is a continuous task.