Blender.jp

2年前、私たちは2.6x期間を「ブランチマイグレーション」に集中するようスケジューリングしました。そしてここ数年、私たちはこの作業の結果を、Blender の大量の新しいツールとエディターとともに見てきました。
すべての2.6x ビルドは2.5xと（ほとんど）互換性があるよう作成されています。

2.6xのナンバーがもうすぐ終わりそうな今、来る数年間のために集中すべき事とプロジェクトを考える時が来ました。以下はここ（訳注：Blender Codeブログ）とメーリングリストで議論やレビューしたいと考えている案です。

[wiki]
**残りの2.6xリリース

-2.68と2.69は互換性を厳格に守り、Blender の安定に集中し続けます。

-不安定になる可能性のある物、または互換性を壊すと思われる物は2.7ブランチに移動されるでしょう。

-必要なら、バグ修正のみをマージした2.69アップデート(a b c d)もあるでしょう。

**Blender 2.7x プロジェクト

2.7x プロジェクトでは、前方と(小さな)後方互換性の破棄が可能になるでしょう。つまりデフォルトで、2.7x .blend ファイルを2.6xやそれ以前で確実に読み込ませなくてもいいということです。後方互換性は依然重要ですが、大きく重要な改良のみ許容すべきだと思われます。変更には UI レイアウトやオプション名、テーマ、デフォルトのショートカットの見直しなども含まれるかもしれません。

しかし、Blender 2.7xバージョンに非互換性をずっと追加し続ける場合、最後の2.69リリースの重要な修正による更新を続けていくこともあるかもしれません。

これはまた、Blender のコーディングを Git に移行するのに最適な期間でもあります。

この期間に適したプロジェクトとターゲットのまとめ：

-最小構成を OpenGL 2.1へ移行（つまり、オフスクリーン描画のような、これが必要な UI/ツール設計が可能に）

-依存グラフ(Depsgraph)のリファクタリング、スレッディングによる更新など

-デュプリケーターシステム、アニメーションプロキシの修正（リンク・参照データのローカル部分用）

-3Dビューポート描画の再設計（space_view3d モジュールのフルクリーンアップ）

-ビューポートの CPU ベースの選択コードへの作業

-シーケンサーの書き直し

-アセットマネージャー、リンクを処理するいい UI とツール

-Python「カスタムエディター」API（イベントハンドラ、ノーティファイアーの Python 対応の改善など）

-UI: デフォルトのリフレッシュ

**Blender 2.8x プロジェクト

私は2.6x と2.7x の作業が終わるまで2.8xバージョンを待つことはないと提案します。別に数字どおりにリリースする必要はないのです。近い将来、最初の2.70の作業をしている間に、2.8x 用のプロジェクトがすでに開始している可能性もあるのです。

2.8x では、多数の非互換性を伴う、大幅な書き直しを行うプロジェクトを目標とします。例えば、

-新しい「統合物理演算」システム。Bullet を多用し、ポイントキャッシュを一元化（Alembic）。

-パーティクルノード（しばらくは旧パーティクルも共存させるでしょうが）

-Blender のもっと多くの部分の改造（モディファイアー、コンストレイント）

-ゲームエンジン…（下記）

-OpenGL 3.0?

**Blender 3.0 プロジェクト

すべての2.x プロジェクトでは現存の C コア、Blender ファイル、データ構造(DNA)、Blender のシーン/オブジェクト/データメソッドをできるだけ守る予定です。しかしこれには限界があります ― 90年代中頃から非常にうまく生き延びてきた設計ですが、20年も動作するとは予測していませんでした。
これから数年間、私たちはこの主題に取り組むため、wiki に私たちの持つ問題、希望リストと設計アイデアを集めようと思います。

**Blender ゲームエンジン

描画と更新のスレッド化、ビューポート(コンポジティング)エフェクト、物理演算の統合、ノードベースのアニメーション、そして現在 Blender ですでにリアルタイムでできる物すべての作業が進行中であることを踏まえ、私は現在のゲームエンジン(以下 GE)をこの作業にもっと再利用することを提案します。

徹底的に言えば、私は GE を Blender コードのもっと重要な部分にすることを提案しているのです。もう別になんてしません。
これにより対応と安定性が進み、作業がもっともっと楽しくなります（と確信しています）。

"GE" と呼ぶ代わりに、単に Blender 内での「インタラクションモード」と呼びたいと思います。以下のようなことが考えられます。

-「ロジック」のコンセプトのアニメーションシステムへの統合。規則や挙動を元にしたアニメーション（群集アニメーションなど）が大幅な進歩を遂げます。

-すべての Blender 物理演算に対応。

-インタラクティブ再生用へのスピード最適化により、通常の3D編集も（そして逆も）恩恵を受けます。

-ロジックスクリプティング用の Singular Python API。

-レンダーエンジン同様の、強固な外部ゲームエンジンとのI/O 統合。

この時破棄すべきアイデアは、Blender に「真の」ゲームエンジンを内蔵することです。私たちは移植性と Unreal や Crysis…Unity3D 程度の品質さえも持たせることができなかったことを認めざるを得ません。そして Blender の GPL ライセンスはいずれの役にもたたないことも。

いい面に目を向けると、私たちの GE の一番クールな機能は3Dツールへの統合であり、ウォークスルーや科学的シミュレーション、ゲームのプロトタイピング用の3Dインタラクションを作成できることだと私は考えます。
もし、この（本来の）デザインを GE に取り戻したなら、依然、リアルタイムと「オフライン」3Dのシームレスな統合による、ユニークでクールな何かを得られるのではないかと思います。
[/wiki]

Ton Roosendaal
2013年6月