トップ 差分 一覧 ソース 検索 ヘルプ PDF RSS ログイン

独り言日記(2004/08)

独り言日記

浮動小数点除算(2004/08/27)

浮動小数点の除算を考えてみます(トートツに・・・)。

浮動小数点に限らず除算処理はコストがかかる(クロック数を消費する)、というのはよく聞かれます。これは、整数除算でも同様です。整数除算では内部的には以下のようなループが走ることになります(以下は32ビット/32ビットの除算。符号なし除算とお考えください)。

unsigned long mask;
unsigned long a, b;
int cnt;

mask = 0x80000000;
a = 0;
b = 0;
cnt = 32;

//val / val2を計算する
while(cnt--) {
    a <<= 1;
    if(val1 & mask) a |= 1;
    val1 <<= 1;
    b   <<= 1;
    if(a >= val2) {b++; a -= val2;};
}

「val1/val2」を計算し、商がb、余りがaに入ります。ここで32回ループが発生するということは、最低でも32クロックの消費が表面化してしまいます。

浮動小数点では、というと符号部の計算は乗算と同じように符号だけで計算してしまいます(乗算と同じでXORで求まる)。

そして仮数部を取り出して整数除算するわけですが、このときに仮数は32ビット浮動小数点の場合は0x00800000のビットが必ず1になっています(仮数部23ビットを取り出して上位に1ビットを追加するため)。そして00800000〜00ffffff以外の値が入ることはありません。こうなると、仮数部レベルで割られる数が最大(0x00ffffff)で割る数が最小(0x00800000)であっても、答えは0または1になってしまいます。

ですので、割る数のほうを大きくしてやります(たとえば48ビットにする(左に24ビット分シフトさせる)、とか)。そして仮数の結果を先に求めておきます。計算式は上記の整数除算のを48ビット除算とするとOKです。乗算と同様に除算結果の最上位ビットより検索し、1となるビットまで進めます。そこから24ビット分が仮数になります(ただし、上位の1ビットは省いて残り23ビット分を仮数として採用)。この最上位ビットから検索して1となるビット位置が、一番下位ビットから見たときに22ビット目に存在した、とします。

そして指数部ですが、乗算のときは(e1 + e2)のように加算しましたが除算のときは(e1 - e2)と引くことになります。

e = 22 - ((48 - 24) - (e1 - e2));

このeが最終的な指数になります。「22」は結果の48ビット値のうち、最上位ビットから検索して1が見つかったときの仮数での(最下位ビットから数えた)ビット位置とします。「48-24」は、48ビットの結果は実際は割られる数を2^24倍してますのでそれを元に戻しています。

最後に符号部・指数部・仮数部をORで合成すると、それが最終的なfloatでの除算の結果になります。

val = sign | ((e + 127) << 23) | 仮数部23ビット;

以上で浮動小数点での四則演算を説明しました。が、実際はPCではこれを実装することはないかなと思います(すでにFPUが実装されているわけですから)。しかし、もっとハード寄りの設計が必要になると(極端に言うと)論理演算と整数加減算以外は使えない、なんてこともありますのでそのときは役に立つかも・・・。

でもマイナスの値をプラスにするってのとかは応用が利きそうですね。

float fDat = -2.265f;
if(fDat < 0.0f) fDat = -fDat;

とはせずに

unsigned long *pL;
pL = (unsigned long *)(&fDat);
*pL = (*pL) & 0x7fffffff;

で、浮動小数点数の符号がマイナスの場合にプラスにできますし。条件判定がないので利用価値ありかと。「fabs(fDat)」とするのはどちらが速いかはベンチしてないので分からないですが(^_^;;。

その他、「限りなく0に近い場合に0に補正する」ってのも

if(fDat > -(1e-6) && fDat < (1e+6)) fDat = 0.0f;

という部分をもっと簡略化できますね(符号部はプラスになるようにして指数部のみで比較)。

浮動小数点乗算(2004/08/25)

XMLパーサは完成しました。レンダラだけでなくて結構汎用的に使えそうです。

さて、以前「浮動小数点加算」について書きましたが次は乗算です。こっちのほうが簡単です。

たとえば、「-12.5 x 0.05」って普通に計算するにはどうするでしょうか?符号は別処理して「マイナス x プラス = マイナス」とし、「125 x 5 = 625」を計算して指数は「-1 + (-2) = -3」なので「0.625」、符号も考えて「-0.625」と答えを出すと思います。これとまったく同じ考えです。

「C = A * B」を考えるとき、符号部を考えます。

符号部は論理演算では「(Aの符号ビット) XOR (Bの符号ビット)」で求まります。A、Bが共にプラスの時はXORを取ると0になります。A、Bが共にマイナスの時はXORを取ると0になります。A、Bの符号が異なる場合はXORを取ると1になります。

val1/val2にfloat型の浮動小数点値が入っているとすると、

sign1 = val1 & 0x80000000;
sign2 = val2 & 0x80000000;
sign = ((sign1 ^ sign2)) & 0x80000000;

このsignがA * Bの結果の符号ビットです。

次に仮数部。

仮数部は取り出すと「1.xxxx」の形になります。仮数部23ビットの場合は先頭に1ビット追加して24ビットで計算できます。

LVal1 = (val1 & 0x007fffff) | 0x00800000;
LVal2 = (val2 & 0x007fffff) | 0x00800000;

で取り出せます。これで24ビットの仮数になってます。

乗算は、(2進数での)「1.xxxx」x「1.xxx」を計算してしまいます(実際は24ビット同士の整数乗算となります。が、結果が48ビットになるために64ビットにキャストして計算します)。

__int64 i64val = __int64(LVal1) * __int64(LVal2);

この結果を上位ビットからみて1が出るまで検索して、「1.xxxx」の形の「24ビット」を取り出します。

ファイルが存在しません。

上記の図のように、24ビット x 24ビット乗算の場合は、結果として48ビットの範囲が必要です。そして、下位ビットからみて「45ビット目」に1が存在するとします。

ここで仮数として23ビット分を取り出すわけですが、それより下のビットはというと・・・切り捨てます。ようはこれが「丸め」になるわけですね。つまり「誤差」がココで生まれます。仮数部が大きければ精度が高くなるというのがなんとなくですが分かるかと思います。

そして、最後は指数部の計算です。

e1 = ((val1 & 0x7f800000) >> 23) - 127;
e2 = ((val2 & 0x7f800000) >> 23) - 127;

として、2つの数val1/val2の指数を求めたとします(32ビットのfloat型浮動小数点フォーマット)。

e = 45 - ((23 + 23) - (e1 + e2));

これが最終的な仮数部の値となります。

val = sign | ((e + 127) << 23) | 仮数部23ビット;

で求めたvalが「A * B」のfloat乗算の答えに相当します。小数点位置を合わせるという手間がない分楽ではありますが、ここでのネックは「int64(LVal1) * int64(LVal2)」の乗算ですね。FPUではこれらの計算をひっくるめて「浮動小数点乗算」としてハードウェア実装しているんだと思われます。

これで少しはブラックボックス化されているように見える浮動小数点演算が垣間見れる、かな。

実際は誤差処理の繰り上りやオーバーフロー・アンダーフロー処理など、細かい調整がされていますがそれはFPUによってまちまちみたいですね。(Athlonはエラー処理が甘いような(はしょってる?)・・・だから、出た当初は浮動小数点演算がPentiumよりも速い、なんていわれていたんだと思ってたりします)

XMLパーサを作る(2004/08/23)

同じ日の日記二日目。

レンダラにてファイルからデータを持ってくるときのフォーマットをどうしようか、ということで(Java好きな私として)XMLで扱うことにしました。

ITの世界(なんて言うと変ですが)では、データをXMLで扱うというのは結構浸透していたりします。これは、テキストのフォーマットでフォーマットが規約化されている、取り出すための「XMLパーサ」が多数存在するというのも大きいかと思います。後は、ネットにデータを散布した場合の可読性なども。

XMLの取り出しの種類(XMLパーサの種類)としては「DOM」と「SAX」があります。一度メモリにXMLツリーの情報を読み込んで処理する方法が「DOM」で、イベントを呼び出して前から順にシーケンシャルに処理していくのが「SAX」です。「SAX」のほうがはるかにメモリ効率も処理時間も軽いです。

XMLパーサとしては「Xerces」などが有名ですが、文字コードの判別がいるため比較的重くなるのがネックです。文字コードをUTF-8/Shift-JIS/EUCくらいに絞るのであれば自前で作ったほうが軽いしメモリも少なくて済みますね。ということでXMLパーサ(SAXで処理)も作ってます。

ところで、トップページ「http://ft-lab.ne.jp」を更新しました。「MarbleCLAY」を開発されているMaeさん(ESCARGOT)が3D開発者の参加するWebringを立ち上げましたので参加させていただいております。今一度、3Dの開発を含む3DCGが盛り上がっていけばいいな、と願っています。

浮動小数点加算(2004/08/23)

さて、A+Bの32ビット浮動小数点加算を考えてみます。「指数」によって小数点位置が動きますので(これが「浮動」という理由です)実際の範囲-127〜+127の間に仮数部である23ビット(実際は先頭に「1」を追加した24ビット)が存在する、という感じをつかむことが大事です。

ファイルが存在しません。

加算の場合は、指数が大きいほうに合わせて指数の小さいほうをシフトします。そしてビットの上位より24ビット分の加算を行い、これを仮数部とします(実際は桁上がりを考えて上位1ビット以上をプラスして確保しておくこと)。実際は24ビットギリギリではなく32ビット分を加算するといいでしょう。

指数は(2進数で)1.xxxxの形になるようにビット先頭よりたどり「1」である位置を検索して決定します。

ですが、単純にはいかない部分もあり、実はIntelでのネイティブなFPUでのfloat加算とAMDでのfloat加算では結果が違ったりします。これが誤差(無視できるレベルですが)になるわけですが、実際は23ビットより小さい部分の(切り捨てる部分の)繰り上がりを考慮していると思われます。(ハードウェア設計の方にも聞いたのですが、このあたりはなかなか一致しない、とのことです。たぶん企業秘密なんだろうなぁ)

マイナスの値が絡む加算の場合は2の補数をとって、結果がマイナスのときに符号反転をする、などの必要があります。(これで減算は加算で表現できる、ということが分かります。なんで、コストを抑える場合は減算は実装しないです)

浮動小数点での内部計算は2進数の世界、シフト演算・論理演算の世界です。(割とハードウェア化しやすかったりします)仕事でその浮動小数点モジュールを作ったりしましたが(ソースは残念ながら出せないのですが)繰り上がりの考慮など微妙な調整が発生しますねぇ。

実は、加算(減算)処理のほうが乗算・除算よりも実装の手間がかかります(計算前のシフト処理が発生するため)。しかし、計算時間のほうは加算<乗算<除算の順に重くなります。

話が変わりますが、3DCGに関するTipsを徐々にですが追加していってます。このページの左のメニューより「3DCGプログラミング」をたどっていってください。また時間が出来次第追加していきます。

32ビット浮動小数点(2004/08/19)

float型(32ビット単精度浮動小数点)のフォーマットは以下のようになっています。

ファイルが存在しません。

符号部(S)  1ビット: 0..正、1..負
指数部(E)  8ビット: 実際の指数 + 127
仮数部(F) 23ビット: 実際の仮数 - 1(1.xxxの形に正規化し、1.0を引く)

仮数部に格納する値を「1.xxx」の形に補正後、これを2の何乗するという「何乗」が指数部になります。これらで扱うのは2進数の世界になります。

たとえば、浮動小数点数をunsigned long型にしてメモリ内の数値を見た場合、以下のようになります。

 0.0f  → 00000000
 1.0f  → 3F800000
-1.0f  → BF800000
3.625f → 40680000

0.0fの場合は例外的ですので、別処理で0x000000を返すといいです。ここで「3.625f」を取り上げてみましょう。

まず、整数部を小数部を分離します。このあたりは情報処理二種の出題範囲ですね。

3.625f = 3.0f + 0.625f

「0.625f = 0.5f + 0.125f = (1/2^1) + (1/2^3)」です。これより、2進数化すると以下のようになります。

3.625f → 0011 + 0.101 = 11.101

これを単精度浮動小数点にあらわせるように正規化します。ここでの正規化とは、仮数部が「1.xxx」の形になるようにシフトする処理を指します。この段階で指数が出てきます。

11.101 = 1.1101 * (2^1)

このときの「1.1101」が仮数部になります。2の累乗の「1」が指数部になります。もういっちょ、格納前の補正を。

  • 仮数部 - 1を行います(1.1101 - 1 = 0.1101)
  • 指数部 + 127を行います(1 + 127 = 128)

これらより、符号も考慮して合成すると、

符号部 = 0x00000000
指数部 = ((1 + 127) << 23) 
        → 0x40000000
仮数部 = 0.1101(←これは2進数) → 23ビット目に先頭の1が来るようにシフト
        → 0x00680000

結果「3.625f → 0x40680000」となります。

ということで、float型のfDatより、符号・指数部・仮数部の情報を取り出すのは以下のような感じです。

unsigned long LDat;
int e;
unsigned long f;
unsigned long s;

//16進数変換
LDat = *((unsigned long *)(&fDat));

if(!LDat) {
    //値は0.0fなので、そのまま
}

 //符号部の取り出し
 s = LDat & 0x80000000;

 //指数部取り出し
 e = (int)((LDat & 0x7f800000) >> 23) - 127;

 //仮数部の取り出し
 f = (LDat & 0x007fffff) | 0x00800000;

シフトと論理演算だけで完結します。

これを、符号部1ビット・整数部16ビット・小数部15ビットの32ビット固定小数点にコンバートするには、以下のような感じです。

#define N    15

int e2;
unsigned long val;

//整数部16ビット・小数部15ビット分のみ取り出し
//==> 32ビット幅の領域内に、15ビット目が指数位置となるように
//移動してくる
e2 = 23 - e;
if(e2 >= N)  val = f >> (e2 -  N); 
else         val = f << (N  - e2);

//16 + 15ビットに収まるようにマスク
val &= 0x7fffffff;

//負の数の場合の反転(2の補数)
if(s) val = (~val) + 1;

変数「val」に固定小数点での値が入ります。意外にすっきりしますね。上記のN(15)のところを変えると小数部Nビットでの固定小数点が表現できます。「2の補数」というのは、プラスをマイナスに・マイナスをプラスに符号反転する処理です。これは、全ビットを反転して+1すればOK。

固定小数点を使う場合は浮動小数点と固定小数点の相互変換はよく使うのですが、浮動小数点のフォーマットさえ分かってれば簡単です。また、シフトと論理演算・加減算で表現できるため負荷も軽いです。

ハードウェア実装時(FPUを作る場合など)は、このあたりの最適化が肝になりそうですね。

意外とやっかいな小数計算(2004/08/18)

今のパソコンは標準でFPU(昔で言う数値演算コプロセッサ)がついているため、「浮動小数点」の計算はなんの躊躇もなく使用できます。これは、ハードウェア的に浮動小数点演算(加減乗除算などの)処理が実装されているからです(なので速く処理できている)。

しかし、ハード的な低レベルな実装をする場合は「固定小数点演算」がいまだに生きていたりします。これは、小数位置が変わらずビット幅が固定範囲の実数値を表すときに利用します。大雑把に言うと「小数を含む実数値を1024倍して整数で管理している」みたいなものです。が、誤差が大きいのと(ぶっちゃけこのあたりはレイトレレベルでは無視できます)表現範囲が狭いのがネックです。ですが、加減乗除算のコストは整数演算のそれとほぼ変わりません(演算処理+シフトで足切りするくらいです)。

「固定小数点」では表現範囲が狭いというのが一番ネックで、ものすごい大きな値と極小の値の乗除算などは特に誤差を生みます。

レンダラの場合は、この誤差が品質に影響しますのでやっぱり「浮動小数点」での扱いがいいなぁ、というのが私の最近の結論です(いろいろ遠回りして見つけ出した結論だったり(^_^;;)。速度は犠牲になりますけどね。

で、意外にも浮動小数点の加減算は難しかったりします。

float a, b, c;
a = 10.0f;
b = 12.5f;
c = a + b;

となにげに計算できますが「もし、FPUがない場合はどうするのだろう」と考えると符号部・指数部・仮数部をバラバラにしてからシフトを駆使して演算する必要があります。

実装してみると、なるほど普通の整数演算よりも時間がかかるというのが把握できますねぇ。

その前に一般のPC上の浮動小数点(IEEE)の説明からしてみます。float型(32ビット)で「符号部1ビット/指数部8ビット/仮数部23ビット」で表現されています。

float fDat = 10.125f;
unsigned long LDat;
LDat = *((unsigned long *)(&fDat));

とすることでfDatに入った値を32ビットの形(LDat)に抜き出してきます。と、今回はここまで。

ネタとして、日記では「浮動小数点」について書き下ろしていくことにしますね。ちなみに、固定小数点←→浮動小数点の変換、浮動小数点同士の加減算(FPUを使用しない)は、乗算・除算を用いることなく実装することができます。

東京湾大華火祭(2004/08/14)

東京で今年最後の(と思う)大きな花火大会「東京湾大華火祭」というのに友達と行ってきました。東京湾の海上から打ち上げる花火です。

隅田川花火大会と違い、地べたに座ってじっくり見ることができました。で、デジカメで花火の写真を撮ってもらったのでアップです(ここにアップしてるんでCGかと思われるかもですが実写です(^_^;;。事実、現在はGIの普及によりCGと実写の境界線があいまいになってはきていますね。花火みたいなエフェクト(?)は昔から変わらないでしょうけど)。

ファイルが存在しません。

実際は、バンバン上がってまして結構きらびやかだったです。最近は記号(☆など)とか顔(にこちゃんマーク)とかも出せるので凝ってますねぇ。技術的な思考のもの(時間差や記号・顔を描く)と昔ながらの芸術的なもの(菊とか柳とか)があるなぁ、と思った次第です。でも、大き目の花火が天高く昇って咲くってのが一番歓声が上がっていて時間差で届く音とあいまってよかったです。

ところで後ろで座っていた家族連れのお父さん、子供が花火を見たいと言っているのに必死に帰るための策略を練るのはどうかと(^_^;;。家でお寿司を用意しているだのテレビがどうだのでせかしていました(見ていて飽きてきてたんでしょうねぇ)。せっかくの機会なのに、後30分(最後に大きいのが来るのに・・・)を残して帰っていきました。

いやぁ、でもやっぱり花火はわびさびがあって風流ですなぁ。

その後、もんじゃ焼き屋で晩飯を食べながらテレビを見ていると、アテネ五輪の柔道で谷亮子選手が金メダル取ってました。いやはや、いいですね。開会式はぶっ通しで見ていたのですが(谷選手は開会式に出てなかったのですが)、まさか怪我を押して優勝するとは・・・。

・・・おかげで終電ぎりぎりでダッシュで走りましたけど(^_^;;。東京駅で激しく飛ばしてました(^_^;;。家に帰ってニュースを見ると、野村選手も金取ってましたねぇ。

五輪と花火でいい思い出になりそうです。

新しい知識の習得(2004/08/11)

レンダラのほうと平行して、いろいろ新しいことにチャレンジしています。これは完全なる趣味なんですが、ピアノのほう(バイエル)は50番まで進み、あともう少しで半分クリアすることになります。2週間ちょっとで半分だと早いほうかな。

本当だと習いに行くのが王道で(自己流では変な癖がついたりするらしい)、またキーボードだと軽すぎて実際のグランドピアノでは弾けなくなる、らしい・・・。が、耳コピー・作曲が今後楽にできるようにするための特訓なので気にしないです(^_^;;。そういやテンポが適当なので、これは実際に時間を測ってやるべきですね。・・・そうだ、Flashでメトロノームを作ろうかな。

その他、プログラムはプログラムでもハードウェア方面(組み込みの)も仕事の関係でやってたりします。兼勉強もかねてやってます。実際は私自身はハードウェアに触らなくてもいいんですけどせっかくなんでいろいろ実験してます。低レベルでたたくってのもなかなか面白いですね。LED点灯させたりが楽しいです(笑)。デジタル時計の(全部点灯させると8と出るやつ)を「7セグメントLED」というのですが、これで16進数を表示したりという単純なことだけでも面白いです。時が来たら、このあたりも知識として広めていきたいですねぇ。恥ずかしながら今年の4月ごろまではまったく知らなかったハードウェア分野なんですが、おもしろいのなんの。

RS-232C(2004/08/09)

PCととあるハードウェアをつなぐために、RS-232Cのケーブルを秋葉原で購入。いつも端子部分の形状(ピン数とオス・メス)で間違うんだよねぇ〜、と思っていたら案の定間違ってました(T_T)。またやってしまいました(汗)。プリンタ・RS-232Cがらみで購入した無駄ケーブルのレパートリーがまた増えました・・・これで歴代累計3つめ・・・。適当に品定めしてその場で買うのはあきませんなぁ。

で、本日2回目の秋葉原出陣でようやく正しいのを購入してきました(必要なのは、D-Sub25ピンのオス〜D-Sub25ピンのメス、のケーブルでした。これって「延長ケーブル」という立ち位置なんすね)。

ところで、初めて秋葉原の「ラジオ館」と呼ばれる電子パーツの店(石とかコンデンサ、LEDなどの部品が置いてある店)が密集しているビルに入りました。奥まった裏道や表通りでもそんなところがありました。もう、別世界でびっくりです。店の店員さんが結構高齢者が多くて、客層も結構年齢高かったです(店員・お客さん共に、ほとんどが見た目60歳は超えてたかな)。その区域だけ20年はタイムスリップして戻った感じです(独特の照明と古臭いにおいと)。店のおばちゃんが「この抵抗の容量はうんたら・・・」みたいな感じで語ってたのには職人を感じました(^_^;;。このような方々から見ると、「パソコンを組み立ててます〜」といってマザーボードを買ってる我々はお子ちゃまなのかもですね(^_^;;。しかし、世界が違うと人も違いますねぇ。もしかしたら、今のコンピュータ世代が年を取ったら職人的な渋みが出てくるのかも。また、電子部品の屋台のような感じがイカしてました。

この部分も掘り下げていくと面白いだろうなぁ。

Flash(2004/08/07)

先日、なにげなくTV東京の「たけしの誰でもピカソ」を見ていると「Flashで作品を作ってます」という12才の少年の話が出ていました。いやぁ低年齢化しているということでいいことです。

2chネタになりますが、Flash板というところで「flash★bomb '04」というのが開催されていました。Flashを使った作品を持ち寄ったお祭りです(もう終わっちゃいましたが)。そこでのお気に入り、「HACHIMIRI FILM」さんとこの「Savior Cat」がすごいっす。個人的ヒット。

flash★bomb '04
http://flash.dempa2ch.net/fb04/

HACHIMIRI FILMさん 
http://freett.com/hachimiri_film/
http://freett.com/hachimiri_film/flash/savior_cat.htm

この方まだ10代だそうで、ほんと年齢は関係ないですね。すごい人はすごい!!仕事でFlash使ったりするのですが、なかなか前向きに見ない大人(プロだろう、と言いたい(^_^;;)も多くて純粋な興味がどれほど大事か、ってのを思いますねぇ。

私はがんばる人たちのために情報公開をしたり手助けをできればなぁ(ゆくゆくは作品を作れればなぁ)なんて思ってます。ということで、徐々にですがFlashのほうのTipsも追加中です(^_^;;。

ピアノ練習中(2004/08/05)

とりあえず1日2時間くらいのペースでバイエルにて練習を続けて10日目、ずいぶんと楽になってきました(指が慣れてきました)。で、ただ今39番まで。

1練習曲で2時間くらい過ぎてしまうことがありますが、詰まらずに弾けたら次に進むということをルール化することで確かな上達は掴めているみたいです。

話変わってレンダラのほうは、牛歩前進ですが進んでます。以前、日記にて32ビットは4億まで〜などと書いていたのですが、間違いで(^_^;;「65536 * 65536」なんで4294967296(42億)でしたね、すみませんです。インデックス表現にてオブジェクト番号を32ビット値で、オブジェクト内のポリゴン番号を32ビット値で、とするととりあえずは一般には耐えることができそうです。

最終的にはGIレンダラなんですが、フェイクの煙/炎の表現(パーティクル)・光ってボワッとなる線(もしくは面。雷とかオーラとかの表現用。北斗の拳での青白いブォ〜ッって立ち込めるオーラがやりたい(^_^;;)なども実装できればいいなぁ、と思ったりしています。後は、段階的にファー・ヘアーですね。

私はプログラム専門ではありますが、遠い将来はアニメーション作品を作ってみたいと思ってます(レンダラはそれの道具に過ぎないですし。後、モデラーも作りたいなぁ)。海外ソフト(MAXとかMayaとか)が有名ではありますが、値段もさておき機能が豊富すぎて私には扱いきれないなぁというのが本音です(^_^;;。日本では日本人になじむソフトウェアおよびインターフェースを考えることができるはず、ってことで模索していきたいところですね。

まだ、初心者(私含む・・・っていつまでも初心者と言ってますが)には現状の3Dソフトはやさしくなくて難しい・人を選ぶものであると思ってます。もっと「こうなればいいのに(逆に、この機能は初心者には難しすぎるので削るなど)」とかいう部分は、やはり自分で作るしかないのかなぁ。上級者層はMAX/Mayaなどでいいかもですが、初心者に優しいのは・・・となると現在の3Dソフトでは「これ」と言ったものがない気がします。そのへんのスキマが狙い目かな・・・と思いつつ、数年経過・・う〜む。

Future's Laboratory 技術格納庫 2004-2013 Yutaka Yoshisaka.