オープンソースの人体モデリングツール『MakeHuman』のAPI開発プロジェクトがスタート

オープンソースのクリエイター向けGUIモデリングツールのMakeHumanがついにAPIの準備を始めたぞ。現状でも、中身のPythonコードを読もうと思えば読めなくもないんだけど、まあ、しんどかったね。オープンソースだったのに今まで開発者用のAPIが無かったってのも不思議だけど、クリエイター向けだったからかな。これは期待したい。

公式ブログのアナウンス記事をヘッポコ翻訳してみた。↓
The MakeHuman API Project (MHAPI)

新参の開発者にとって、MakeHumanの内部構造を把握するのはかなり難しいことだと私達は経験的に知っています。
また、MakeHumanのソースコードに多数の修正を加えていくと、必然的にその複雑度は増していきます。
私達は新参開発者のために、そしてMakeHumanより簡単にを拡張できるようにするために、MakeHuman API Project (MHAPI)を始めます。

スポンサーリンク

モチベーション
通常、ソースコードというものは技術指向なものです。
あなたが何かプログラムを作る時、そのプログラムが動くことを第一に考えるはずです。大抵の場合、あなたは技術的な実装を中心に構造を作り、呼び出し処理や、技術的な実装に対応したサブルーチンを追記していくことでしょう。
このやり方の利点は、コア機能がむき出しの状態なので、あなたは直にそれにアクセス出来るという点だ。つまり、あなたは何の制約もなく自由にできるということだ。
このやり方の欠点は、どのように変更・改良を実装するかを考える前に、まずこの技術はどのような構造で、どのように実装されているのかを詳細に把握しなければならない点だ。
この欠点は、技術指向のAPIでも同様である。機能の呼び出し方が分からない時は、まず実装技術の詳細を理解する必要があり、利用可能かどうかはその後に知ることとなる。言うまでもなく、その技術がどのような構造で実装されているのか理解していなければ、正しく使う呼び出し方を見つけるのは非常に難しいだろう。

スポンサーリンク

別のAPIの構成方法として、技術的な実装ではなく、タスク指向で、概念を中心に捉える方法があります。この方法では、まず最初に、あなたが何をしたいのかを知り、それができる呼び出しを探す。ここでの呼び出しは、実装の詳細ではなく、コンセプトに沿って構成される。これには利点がいくつかあり、新参の開発者でもスムーズに開発に着手でき、APIに対して書かれたコードの意図が明確になり、バックグラウンドの実装が変化してもAPIを安定した状態に保つことができる。
この構成の欠点は、コードの記述方法と実際の動作方法が乖離してしまうという点と、APIを最新の実装技術に保つためのメンテナンスコストがかかる点である。

ビジョン
MHAPIプロジェクトの目標は、DSL(ドメイン固有言語)に近づけること、すなわち、意図で呼び出せて、とても使いやすいPythonベースのスクリプト言語にすることだ。APIは、まずはプラグイン経由で拡張機能を記述するものとして開発するが、長期的に考えれば、必ずしもこのような新しいコードを制限する造りである必要はない。我々のビジョンは、基本的なプログラミングスキルを持った人が、APIの解説にざっと目を通した数分以内にMakeHumanのプラグインのコピーを作成するなど、コード開発を始められるようにすることだ。

構造
先に述べたとおり、呼び出しはタスク指向とコンセプトラインに沿ってソートされる。APIのサブセットは以下のようになる(まだ構想段階のため、検討中のレイアウト)
 api
    camera
      zoom()
      move()
      rotate()
      ...
    human
      applyTarget()
      setAge()
      ...
    clothes
      equipClothing()
      setClothingColor()
      ...
    interface
      addButton()
      addTab()
      ...
    messages
      showMessageBox()
      writeMessageToLog()
      ...
この種のAPIで、人間に帽子をかぶせるには、例えばapi.clothes.equipClothing(“fedora”)といった1つの簡潔な呼び出し方法が必要だろう。ボタンや機能を持ったタブの追加も、同様に簡単にすることを目指している。
上記はすべて一例にすぎないということに注意してほしい。APIの設計が完了したわけではない。