QBOQについてのメインページです

QBOQコーディングルール
QBOQコメントルール

QBOQ(Qboq Based On Qt)の使われ方＆開発方針

3DCG用ツール。モデリングツールは既に定評のあるMetasequoiaがあるので、モーションをメインとするツールにしたい。

メタセコはモーションに関するデータを直接的には保持できない。だから、メタセコ->QBOQの流れはできても、QBOQ->メタセコは情報が失われるので無理。とすると、QBOQ上でモデリングが多少なりともできるほうが望ましい。が、そんな機能まで作ってたら時間がかかりすぎる。
(非埋め込み方式と呼ぶことにする)

RokDeBoneや、Mikotoの様に、メタセコに何らかの形でボーン構造を埋め込み、モーションデータは別に保持するという形が今のところ一般的。開発時間から考えても、かなり妥当と思われる。外部ファイルに依存する。モデルデータに直接触る事ができない。
(埋め込み方式と呼ぶことにする)

基本的には非埋め込み方式にして、インポータで埋め込み方式のメタセコデータをインポートする。モーションとの関連付けには置換ツールで対処する。いいとこ取りな方式。
(複合方式と呼ぶことにする)

QBOQは複合方式をとり、かつモデリング等々の機能をも持たせられるように設計したい。しかし、機能が多すぎると開発に時間がかかる問題がある。そこで、オープンソース、Qt、簡易なインターフェイス、プラグイン主体の機能拡張性をとりたい。

メインプログラムはモデル等々を操作するための手段のみを提供し、（基本的なツールから何から何まで）その他の機能はプラグインによって提供される。メインプログラムは複雑になりやすいので、オープンソースにしたとしても開発してくれる人は少ないと思われる。だから、プラグインで参加してもらえるようにする。(この事をプラグイン主体の機能拡張性と書いた。)3dsmaxなんかはこれに似た設計思想をとっていると聞いたけど、良く知らない。

QBOQのライセンス

オープンソース版のQtのライセンス規定に従い、以下のライセンスのもと開発する。
the GNU General Public License (GPL)

QBOQの対象とするプラットフォーム

OS	QtがサポートするOS (Linux,Windows,MacOSX)
OpenGL	未定(GLSLが使えることを前提とする？)
CPU	未定
Memory	未定
HDD	未定

QBOQの構造

QBOQは以下の要素から構成される。

名称	略称	機能
Node	N	NodeManagerに組み入れられて機能する。それぞれが独自のデータを持つ。
Tool	T	Nodeや、NodeManagerが各種機能を提供するために必要な機能を提供する。OpenGLや、QtなどがToolとなる。ToolはNodeManagerやNodeからいつでもアクセスできる。
NodeManager	NM	Node群とTool群、PlugIn群を管理するためのもの。
PlugIn	P	ユーザーからの指示によりNodeManagerに何らかの作用をするもの。アクティブな時にのみ、このプラグインにメッセージが流れてくる
Resident PlugIn	RP	常にアクティブなプラグイン。常に実行されなければならない処理を行う
User	U	プラグインに指示を出すもの

プラグインの実行

現在アクティブなプラグインと常駐プラグインにのみ(マウスクリックなどの)メッセージが渡される。プラグインはユーザーが明示的にアクティブにすることによってアクティブになる。

プラグイン(P)が何らかの動作をするとき

ユーザー(U)がPを起動させある動作を行わせる。ノードマネージャ(NM)を通してPはノード(N)にアクセスし、Nのメソッドを呼び出す。Nは内部データが変更されるたびにHistoryData(HD)を作成し、HistoryDataLine(HDL)に追加する。そしてNMの持つHistoryLine(HL)に自らのNodeIDを追加する。

動作の終了時にNMはHistorySeparator(HS)を追加する。NMはを追加する前に、HLに載っている全てのNに動作が終了しようとしている事を通知する。この通知を受けたら(例えばOpenGLに渡すデータを更新するなど)各種終了処理を行う。さらに、動作の開始時と終了時にP(or RP)にはメッセージが送られる。このメッセージを受けてPは何らかの処理をする。(例えばアイテムツリーの更新を行うとか、アイテムの情報を更新するとか)

Undo＆Redo処理が実行される時

NMはHLに載っているNodeID群を取り出し、そのIDから適切なNodeのUndoメソッドを呼ぶ。と同時にNMはRedo用のHLにNodeIDをプッシュする。

呼び出されたNは、Undoメソッドが呼ばれるたびにHDLから一つ取り出し、Undoを実行する。実行すると同時にRedo用のデータを作製し、Redo用のHDLにプッシュする。

Redoの場合も同様。

選択処理

選択される要素は以下の通り。

１	頂点
２	辺
３	面
４	ノード
５	キー

どの要素が選択されているかはNが保持する。選択状態(SS)が変化すると、NはNMに選択状態が変更された事を通知し、各選択状態ライン(SSL:SelectionStateLine)に自らのNodeIDを追加してもらう。と同時に選択数を更新する。

NMは選択状態が変化したら、変化した事をP(or RP)に通知する。これによりPは何らかの処理をする。

SSLは上記の選択要素ごとに存在しているラインで、NodeIDを追加していく様になっている。また選択ラインは一番左が最も古く、一番右が最も新しいと定義する。よって、選択が変更された場合は既存の物を除去し、新しいものを一番右に挿入する。さらにNode内部でも選択順序を保持する。以上により選択に順序が付けられる。この順序を使って、Pでは何らかの処理をする可能性がある。

メモリ管理

QBOQにおいて、メモリ管理が重要となるのは、テクスチャーとポリゴン(頂点情報など)。ポリゴンについてはQVectorを使用する。テクスチャーについては特に何もしない。

NodeManagerによるNodeの管理

QBNodeに対しては、一意にQBNode::idを割り当て、QMap〈QBNode::id,QBNode*〉によって管理する。QBNode同士の結合は、QBNode::idを通して行われる。直接アドレスを使用したりはしない。

A <= Bと結合させる場合を考える。結合の種類はQBNode::connectParentとする。Bが結合元(from)でAが結合先(to)である。結合元であるBにとっての親がAだと言う事だから、AはBの親となる。AのID(A_ID)を使って、QMap::find( A_ID )してAを見つけ、Aに結合(相互にリンク)する。

結合が形成されたり切れたりする時のヒストリーデータ(HD)は、結合元に所属する。

QBNode::idは0を使用しない。0は不正なNodeIDと定義する。

どのNodeも内部に参照カウンタを持つ。HDLにNodeIDを追加したりしたら１増える。NMによってNodeがnewされるとカウンタは1となる。そしてその後「作られた」というHDを登録するので、結果的に2となる。そのさらに後でdeleteされるとカウンタは1減って1となる。その後「削除された」というHDを登録するので2となる。結果として、HDL上にIDが残っている限りNodeは生き続ける事になる。参照カウンタが0となったら削除される。