独り言日記
2003/08/31 update.

集合を探す
更新日時 2003/08/31
内容 08/25の日記に書いていた、レンダラの「広大な草原に1匹のアリ」のようなシーンを効率よくレンダリングできないか、というネタを掘り返し。
空間分割前に、オブジェクトごとに別分類する必要があるというのは、だいたい理解できるかと思います。
問題は、その分類の条件。 シーン内にできる、オブジェクトの集まりの「コロニー」の範囲を判別することができれば、 それが分類の境界になるのではと思ったりしました。
なんか、この手のアルゴリズムはすでに確立してそうですね。 単純に求めるとなると、オブジェクト間の距離を求めて距離が短い場合は同じコロニー、と判別することはできます。
が、しかし、これだとN個のオブジェクトがあるとするとN^Nの計算量になってしまいます。
Shadeのようにパートのくくりで分類、でもいいのですが、これだとくくり方によっては効率の悪い分類になってしまう・・・
もっとスマートにいかないものかな・・
Kdツリーだとちょっと意味合いが違うしなぁ・・レンダラ造りでは、当分がこれが悩み項目になりそうです。
本日のテストレンダ
更新日時 2003/08/29
内容 ということで、SRenderをShadeの自由曲面に対応してみました(といいつつ、内部でポリゴンメッシュにコンバートですが)。
XYZ軸と平行なあたりで、スムージングが無効になってますね、それとスキャンライン前処理 と実際のレイをたどる部分での誤差で、ポリゴンの境界部分でノイズが乗ってる部分が見られます。
速度的には文句無しな感じです。

Shade LUXOR SRender
36 秒 22 秒 20 秒

こんな感じ

Shadeのポリゴンメッシュ
更新日時 2003/08/29
内容 プラグインSDKは・・・疑ってかからないとダメですねぇ(^_^;;
自由曲面(例えば円)を作成し、中心で収束させた状態で 独自レンダラ(SRender)でレンダリングすると、 中心部分がノイズが乗ったように抜けてしまう・・・。
で、よくよく調べると、中心付近のポリゴンの法線が(0,0,0)になってました。
さらに探ると、「convert_to_polygon_mesh」で自由曲面から ポリゴンメッシュに変換した形状自身に、1ポリゴン内で まったく同じ位置の頂点を持つポリゴンが 収束させた中心付近に集まっているのを確認しました。 (三角形を4点で表現しているのかな)
一部が多角形じゃなくて、直線状態になってるんですね(でも、3頂点以上で構成されている「ポリゴン」です)。 なので、法線が求まらない。
・・・なるほど〜です、仕様といえばそれまでなのですが・・・
そのへんの苦労を、同じくレンダラプラグインであるパストレーサーもLUXORもたどってきたんですねぇ、 なんか感慨深いものがあります。
身近にウイルス
更新日時 2003/08/28
内容 友達のノートパソコンを家のハブにつないでいたときに、 何もネットにアクセスしていないのに激しくハブが点灯していたため「ウイルスでないの?」 と冗談半分で言ってました。
ところが・・・後にウイルスチェッカで調べてみると「MS.Blast発見!」とのことで マジウイルスだった模様です(^_^;;
再度フォーマットしてOSインストールし直す、と言ってました。
が、今回のMS.Blastによるウイルス被害って「イントラ内部から広がる」ってパターンが多かったそうですね。 部外からのノートパソコンの持ち込みなどで。
(ファイアーウォールなどのセキュリティーは、外からの攻撃には強いけど中からは弱い)
それが蔓延する大きな原因の1つでもあるので、改めて持ち込みは気をつけなければ、と思いました。
・・・ちなみに、うちのマシンは感染してなかったためほっとしました(^_^;;。Nortonバンザイ。
cool.ne.jpのCGI停滞中・・・
更新日時 2003/08/27
内容 COOLのCGIサービス(Perl)はどうも「pl」拡張子は使えなくなり、「cgi」にしないといけない模様。
それよりも、「system("mv ...")」やSendMailが使えなくなったのですが・・・
(SendMailは故意に使えなくしてるようですが、systemは頼みますよ〜〜っ(^_^;;)
あと、「gethostbyaddr」でもホスト名が抜き出せない・・・
しかも、26日の書き込みが(おそらくバックアップでの上書きで)クリアされてるし。
う〜〜ん、困るなぁ・・鯖管は何をしているのやら・・

ところで、ウイルスSobigFが大量にきました。半日で70通以上きてます。 しかも、ほとんど同じIPからです。
さすがにここまで行くと障害になりますね。ご丁寧に、会社の始まる時間に来始めて 定時にぴたっとやんでます。・・・・頼むで・・ほんまに。

マシン名「DELL」で東京在住(tracerootすると、大手町のゲートウェイを通ってます)のプロバイダDTI(dti.ne.jp)の方です(IPは伏せ)。
先方のメーラはOutLook(6.00.2600.0000)。
明日も続くようでしたら、DTIの方にクレーム入れます(こちらは、仕事のやりとりはメールですので さすがにメールボックスパンクしてやりとりできなくなる、とかになるとイタいですので)。
cool.ne.jpのCGI停滞中・・・
更新日時 2003/08/26
内容 掲示板をcool.ne.jpの有料領域に作っているのですが、 メンテが終わったと思ったらソースが丸ごと表示された状態。
パーミッションの設定をしても、CGIとして起動せず・・・
ちょっと待っておこう・・・ということで、掲示板はアクセス不可にしてます。 しばらくお待ちを。
広いシーンにゃ弱かった
更新日時 2003/08/25
内容 SRenderの速度テストにて、「広大な草原に1匹のアリ」のようなシーンにて Shadeの10倍以上遅いことを確認。やっぱし、Shadeのレンダラプラグインとして搭載すると いろいろチェックしやすいです(^_^;;
さて、どうしようかな・・・分割要素をさらに各ポリゴン (またはオブジェクト)サイズや全体で占める割合で分ける必要がありそうですね。
後は、Shadeだからかもしれないですが、 法線が反転していて球形状の一部分だけ黒い、なんて現象も起きてます。
う〜ん・・・
テスト比較
更新日時 2003/08/25
内容 SRenderをShadeのレンダラプラグインとして搭載して、動作・速度チェックしてみました。
Shadeレイトレーサ・LUXOR(デフォルト)・SRenderでの速度比較です。

データ Shade LUXOR SRender
単純 8 秒 2 秒 3 秒
複雑なもの 37 秒 18 秒 20 秒
オブジェクト 7 秒 6 秒 5 秒
オブジェクト複数 77 秒 65 秒 37 秒

上から順に、
こんな感じ
こんな感じ
こんな感じ
こんな感じ

質感設定はまだなので、そのへんは無視してください。
まだSRender自身荒い部分があるのですが、シーンが大きい場合・ポリゴン数が多い場合に LUXORよりも速くなりました。
LUXORは、シーンが大きくなった場合にまだ最適化できるかも、といった感がします。
その他は、同じ1次レイを省略する方法なので似たり寄ったりですねぇ。
SRender
更新日時 2003/08/23
内容 もう、時効(だと思う)ですので情報公開。
今現在、時間を見つけては調整しているレンダラなんですが「SRender」という名前で 今年のはじめに開発をスタートしてます。
「SRender」という命名は、私が勝手につけたプロジェクト名なのですが 「Simple & Smart」なレンダラ、という意味と「スレンダー」という単語をチャンポンしてます。
で、実は某所(ちなみにShade関連ではないです)の企画として作っていたのですが、 予算とスケジュールの折り合いがつかず、 結局は企画自体がボツってしまいました。・・・というよりも、私がシステム業の方に戻ったため、 時間がとれなくなってきた、というのが最大の要因かもしれません。
「自分で作ってたんだから自分のもの」ということで、今は好き勝手にいじってます。 公に技術的な情報も公開できる、ということで、ある意味ボツったけどプラスだったのかな。
もともと、対Shadeとしての1本の3DCGツールを作りたい、という欲が (今年1月末のごたごたの中)浮上していたのがきっかけでもありますので、 せっかくのプロジェクトですので形にはしておきたいなぁ、と思います。
「SRender」自体はライブラリの1つにすぎず、1本の3DCGツールを作る(これも名称が決まってますが今は伏せで) という大きなプロジェクトに内包しております。
まぁ、1人でかんばっていきます(笑)。
機能としては、「Shade - (面光源+ブーリアン)」といった感じです。 後、ボリュームライトもつきます(これはまだ開発中)。
3DCGツールとしては、ポリゴンモデラー・レンダラになります。ターゲットは、初心者とゲームキャラクタ作成用。
初心者用の統合3Dツール(?)って・・・現状はないんですよねぇ・・・(六角とかメタセコはモデラー寄りですし)。 がんばってるのは、個人の開発者が公開してるものくらいかな。
リスクは大きいですが、このへんの「初心者+3D」の市場は、まだ未開拓だと思ってます。 正直、混沌とした(Shadeも含む)現在の市販のツールでは複雑すぎて、一般の3Dにあこがれる人たち(私も(^_^;;) には使いこなせるようになるまでに、挫折するかと(と思ってます。私の場合は、なんだかんだいって一番低価格の「3Dアトリエ」がやっぱり 一番しっくりくるなぁ。ほかは、使いこなせてないです)。
ぶっちゃけると、Shadeはプラグイン作成以外は挫折しました(汗)。建物とかは楽でいいのですけど、 人を作ろうものなら皺地獄から抜けられずに結局挫折。私は、ポリゴンのほうが性に合うようです・・。

最終的にはゲーム作りにたどり着きたい(笑)。ムービー作成にも役立てたいので「スピード命」なんです。
レイトレで安定してくればGIにも手を出したいのですが、これは将来に見送りですね。
・・・といいつつ、何本か平行して仕事が動いている現状は、あくまで趣味レベルでしかない 優先度の確保できにくいものなのですけども(^_^;;
徹カラ
更新日時 2003/08/22
内容 関西の友達が遊びに来たため、ひさびさに徹カラ(徹夜でカラオケ)決行(笑)。
ちょっとした発散に持ってこいです。6-7時間もやれば、逆に体力使ってストレスになりそうですが(^_^;;
楽しかったです。

レンダラ、さらに高速化しました。
総合計768440ポリゴンのシーンは、34秒まで短縮(画像は08/19のを参照してください)。 当社比(^_^;;で2倍です。LUXORの速度に追いついたかな。
ということで、「Shade標準レイトレースレンダラはまだまだ速くできる」ですねぇ。
カリカリにできているため「追いつけないかも」と思ってたのですが、 軽く(でもないですけど)追い越せました。
あの品質はすばらしいですので、ぜひとも国産3DCGソフトとしてがんばってほしいです(と、あおってみる(^_^;;)。
私の作った経験でいうと「memset」を再度チェック、です。
目標クリア
更新日時 2003/08/19
内容 さらにレンダラの計算時間短縮。
総合計768440ポリゴンのシーンは、66秒(1.1分)まで短縮。
目標の2分を大きく更新しました。
そして、同シーンでのShadeのレンダリング速度75秒も上回りました。

こんな感じ

「memsetがボトルネック」というのがわかってから、これを中心に最適化すると結構速度に貢献した感じです。
まだ、アンチエイリアスや反射・屈折での最適化が終わってないのでこれをクリアすると、 ほぼ「Shadeよりは速い」になるかも。
memsetの罠
更新日時 2003/08/19
内容 レンダラの速度をどうにか上げようと思い、ボトルネックをたどると「memset」にてかなりの負荷があることが判明。
3DDDAにて、空間内をたどるときに「一度交差判定を行ったポリゴンの識別」の意味で、 ポリゴン数分のフラグ立てメモリを確保しています。
これを、3DDDA開始時にmemsetで0クリアしているわけです(ポリゴンと交差判定をした後は、1を立てる)。 しかし、これが重い・・・
10万ポリゴンのデータだと、

  char m_PolyFlag[100000];

のような感じになるのですが(もちろんmallocで動的確保です)、すべてのクリア処理は

  memset(m_PolyFlag, 0, 100000);

になります。
で、これが3DDDA(レイとの交差計算・影の計算・反射時の走査など)が呼ばれるたびに処理されるとすると かなりの重さになります。サイズが小さければいいのですが、大きくなれば鬼の負荷です。 (これを、アセンブラで4バイト境界で一括して行ったのですが変わらず)

ですが、「ポリゴンとレイが交差した」とフラグを立てるのは、空間分割の1ボクセル内に含まれるポリゴン数分くらい。
つまりは、数十個のチェックのクリアくらいは、forループで回したほうがむしろ速い、という逆転現象が起こります。

で、そのへんを考慮して、19215ポリゴンの形状にてレンダリングテスト。
状態 オリジナルレンダラ Shade
影なし 1.90秒 4秒
影をつけた 5.38秒 7秒
影+アンチエイリアス 9.76秒 9秒
影+反射(アンチエイリアスなし) 13.2秒 12秒

確実に速くなってます。
これは、ポリゴン数が多いほど敏著なようで、 総合計768440ポリゴンのシーンは、199秒(約3.3分)まで短縮(先日は1182秒(約19分))。
ようやく実用的な速度まで落とし込めました。まだまだ微調整する部分は残してますので、 このシーンでは、めざせ2分台です。
レンダラ調整 その3
更新日時 2003/08/18
内容 レンダラをいろいろ微調整。シーン(特にポリゴン数が多い場合)によっては、 約2倍の速度が出るようになりました。
19215ポリゴンの形状にて。
状態 オリジナルレンダラ Shade
影なし 1.90秒 4秒
影をつけた 6.79秒 7秒
影+アンチエイリアス 11.8秒 9秒
影+反射(アンチエイリアスなし) 18.4秒 12秒

ただし、まだまだ大きなシーンでは速度落ちします。
総合計768440ポリゴンのシーンは、1182秒(約19分)まで短縮(前は1473秒(約24分))。
5分も短縮できたとみれますが、まだまだ・・・1/10くらい(約2分で完了するように)にはしたいところです。
依然空間分割は等分割のグリッド式ですが、シーンのポリゴン総数により動的に分割数を変えるようにしました (最大200*200*200)。これが威力を発揮しているようです。
で、そのへんはえらい人のソースコードを参考にしました(笑)。

藤田将洋さんのホームページ
http://web.sfc.keio.ac.jp/~syoyo/

「lucille」というGIレンダラのソースを公開されてます。
あまり人様のソースを見ないのですが(仕事では見ますが)、これは勉強になります。

現在問題にしている「768440ポリゴンのシーン」では、空間分割だけでなくて別の手法で高速化するしかないかな、といった感じです。 (無理矢理1024*1024*1024分割してみたのですが、速度はあまり変わりませんでした)
先は長いです。まぁ、このへんはぼちぼちと。
レンダラ調整 その2
更新日時 2003/08/17
内容 下記方法は、一度シーンをオブジェクト単位でグリッド状に分割し、 さらにオブジェクト内を今度はポリゴン単位でグリッド状に分割する、 という2段構えの方法です。
空間をたどり、オブジェクトにぶつかると、この段階でオブジェクトを空間分割して オブジェクト内でヒットするポリゴンを探す、という具合です。
で、試してみたのですが、そもそもオブジェクト内の空間分割処理で時間がかかるため 実用的でないことが判明(笑)。後メモリも結構食います。
はい、却下。
で元に戻して、空間分割の分割数を少し細かくすることで速度に大きく貢献することがわかりました。
テスト形状で調べると、シーンを32*32*32の領域に分けるとして、1つの格子内に161-200ほどのポリゴンが内包されています。 (そのすべてに対して交差判定が必要)
今度はシーンを48*48*48の領域に分けると、1つの格子内に44-70ほどのポリゴンが内包、とぐぐっと交差判定数が少なくなりました。
ただ、シーン全体でポリゴン数が少ない場合は、この分割数が多くなると逆に重くなってしまいます。
ということで、八分木をもう一回復活させてみようかな。
広大なシーンの場合は、等間隔のグリッドでの空間分割は不得手のようです。
レンダラ調整
更新日時 2003/08/17
内容 レンダラの空間分割にて、効率よくオブジェクトおよびポリゴンを 管理できそうなアイデアが浮かんだので実装中・・・
動的に空間情報をキャッシュしていく、という方法なのですが これだと、レイトレ特有の「レンダリング前に待たされる」という状態を回避できる感じがします。
レンダリングでのプログレッシブJPEGみたいな方法っす、試してみる価値はありそうです。
負荷テスト
更新日時 2003/08/16
内容 そういや立ち読みしたGraphicWorldに、複数のオブジェクトを敷き詰めてレンダテストしてたなぁ、と思いだし、 オリジナルレンダラでも負荷テスト。
8x5=40オブジェクトを配置し、総合計768440ポリゴンを 影のみ・アンチエイリアス無しでレンダリングです。
オリジナルレンダラ「1473秒(約24分)」、Shade「75秒」...

こんな感じ

お、遅い・・・弱点が見えてしまいました(汗)。
オリジナルレンダラは、等間隔のグリッドでの空間分割(32*32*32分割)ですので、 768440ポリゴンなら平均で1マスに「768440/(32*32*32)=約23」ポリゴン入っていることになります(もちろん、局所的に散らばってますが)。
これを1つ1つ交点計算となると、いくら空間分割されているとはいえ、無駄になりますね。
こりゃ一度バウンディングボリュームで刈ってから、その後グリッドをたどらせるほうが効率いいかも。
というわけで、空間分割も修正点としての候補です。
Shadeでのレイトレース 再び
更新日時 2003/08/16
内容 オリジナルのレイトレーサとShadeでのレイトレーサの速度を再度比較してみました。 (Shade 6 REV.20a)
今度は、視点位置・オブジェクト位置・光源位置をすべて共通にしてます(Shadeにて、数値でパラメータ指定できる暫定プラグインを作って配置)。
19215ポリゴンの形状を配置し、平行光源1つ・点光源1つをおいてレンダリングです。

状態 オリジナルレンダラ Shade
影なし 1.95秒 4秒
影をつけた 7.3秒 7秒
影+アンチエイリアス 14.3秒 9秒
影+反射(アンチエイリアスなし) 19.6秒 12秒

こんな感じ

とりあえず、反射は保留として・・・影付き(アンチエイリアスなし)でShadeに追いつきました。
後は、アンチエイリアスをいかに高速にするか・反射でどれだけ「はしょる」か、というのにかかってる感じです。
他の単純な形状だとShadeよりも速い状態。
後、Shadeの特徴として、ハイライトの強いところの反射はどうもスキップしている感じがします(反射しても影響がでないため、かな)。 その他、光源の入射角度と面の法線がかぎりなく垂直に近い場合、影計算をスキップしている予感(これは、私のレンダラでもしてます)。
細かいところでつめていってますね<Shade。
Blaster
更新日時 2003/08/12
内容 ぜんぜん知らなかったのですが、「Blaster」なるウィルスが 猛威をふるっているそうです。
知り合いから電話があるまで知らなかったのですが、某所では ネットワークが壊滅状態だったそうです。
それどころか、いろんな企業で感染しているらしい・・・
Windows2000/XPで感染するウィルスのようです。Microsoft社のサイトで セキュリティーアップデータが公開されていますので、必ずアップデートしましょう。

http://www.microsoft.com/japan/technet/treeview/default.asp?url=/japan/technet/security/virus/blaster.asp

メーラーが何とかは無関係で、RPCポート総攻撃で進入するようです。
Shadeでのレイトレース
更新日時 2003/08/09
内容 オリジナルのレイトレーサとShadeでのレイトレーサの速度を比較してみました。 (Shade 6 REV.20a)
19215ポリゴンを配置し、平行光源1つ・点光源1つをおいてレンダリング。

状態 オリジナルレンダラ Shade
影なし 2.0秒 4秒
影をつけた 9.8秒 7秒
影+反射 23.6秒 15秒
影+反射+アンチエイリアス 32.8秒 19秒

う〜ん、Shadeのほうが速いですね(視野角度が違う・光源の影の落とし方が違う、というのは面倒なので無視してください(笑)。びちっとうまく調整できない・・)。
影なし状態がオリジナルで速いのは、セレクティブレイトレースしているからです。

こんな感じ

ところが、1156ポリゴンの別シーンをレンダリング(平行光源1つ点光源1つで、すべて反射)した 場合は、オリジナル 13.0秒・Shade 18秒という結果になりました。

こんな感じ

オリジナルレンダラの場合は、アンチエイリアスが甘いですね。もっと調整せねば。
空間分割の方法が違うから出る差なのか、影計算が最適化できてないか、いろいろ憶測できるのですが レンダラとしては、まだ調整すべき点が多そうです<ワタシ。
Shadeはさすが、レイトレーサとしては最速の感じがしますねぇ(これは、あくまでも「ごまかし無しの純粋レイトレーサとして」です)。 高速化のための小細工を入れるともっと速くなるんだろうなぁ。
よく、「Shadeのレンダラは遅い」とか言われますが私からすると「速いやん」ってなります(笑)。 実際にレンダラを作ると、それも実感できますわね(他のレンダラをほかに知らないから井の中の蛙かもしれないですけども)。
よく考えると、LUXORだとこれ以上に速いんすね・・上には上が・・
管理システム
更新日時 2003/08/07
内容 仕事用のWeb上の管理システムをPerlで作ってます。
なぜ、Perlかというと「お客さんのマシンスペックがあまり力無いのでしかたなく」です(笑)。
ほんとはJavaを使いたかったのですが・・・やっぱり開発効率はPerlだと落ちますわ (どうも慣れないです、結構使い倒しているはずですが(^_^;;。それよりも、サーバーOSを意識した切り替えがややこしいです)。
すでにPerlプログラムのみで5000行近く行ってるのですが・・・なんとかならんものか・・
といっても、ASPよりも地獄は見なくてもいいのでまだマシではあるのですけどね(ASPで中規模システムを組んだときは、たまらなかったです(^_^;;。 ASP/JavaScript/HTML/VBの構文が入り混じってカオスでした。もう、二度と使いたくね〜です)。
他の言語を使った場合でも同じではあるのですが、サーバー側での処理とクライアント側での画面構築を 同じソース内で処理してやらないとダメ、ってのは何かと可読性が犠牲になりますねぇ。 もちろん、「分離する」という考えはあるのですが(JavaのJakarta Projectなどに、そのへんのモジュールがたくさん転がってます) まだ多様すぎて(仕様が複雑すぎて)ねらいが定まってない感じがしてます。
今や、大半のシステムがWebブラウザを絡ませるので、もうちょっと開発効率よかったらなぁ、と思いますね。
HDD買い換え
更新日時 2003/08/05
内容 OSの不安定な状態はおさまったかと思ったのですが、結局ブルーバックが連発。 原因不明だったので、新しく買ってきたハードディスクに入れ替えました(再度フルインストール中です)。 ようやく安定してきました・・・がいろいろ移行し損ねてます(^_^;;。
IEの「お気に入り」全部消してしまいました・・・。せっかく貯めた技術的なサイトのリンクがぁ・・(T_T)
復旧までには時間がかかりそうです。仕事が詰まっているので早くせねば。
.NET
更新日時 2003/08/05
内容 VisualStudio .NET 2003を入れてみて、パフォーマンスをチェックしてみました。
オリジナルのレイトレレンダラで、19215ポリゴンをレンダリング。

影のみの状態で、11.7秒(VC++6.0)→ 9.8秒(.NET 2003)、
影+反射(最大追跡回数 5回)で、31.9秒(VC++6.0)→ 23.6秒(.NET 2003)、
影+反射にアンチエイリアス4x4 で、48.2秒(VC++6.0)→ 33.2秒(.NET 2003)、
全体的に1.1-1.4倍の速度アップです。複雑な処理ほど最適化されてますね、ぶらぼ〜。

ここ数日OSが頻繁に落ちていた原因は、どうもWindows本体があるCドライブの容量が少ないから、のような感じでした。
氷枕
更新日時 2003/08/04
内容 そういや、実家から氷枕をもらっていたのを忘れてました。 早速冷凍庫から取り出して利用してます。首のところを冷やしておくとずいぶんと快適になりました。
先日、家のマシンが頻繁に落ちている現象は依然おさまらず。Windows 2000 SP4が原因かな、と思ったのですが 数日前までは何のトラブルもなかったのになぁ。
ただ、2ちゃんねるで妖しいサイトを踏んだような予感がするのでそれが原因かもしれません(^_^;;
とりあえず、最新版のWindowsモジュール(IEとセキュリティー関連)をダウンロードしてUpdate・ディスプレイドライバを最新に・ディスクすべてをデフラグ、してみました。
こまめにセーブしつつ様子見状態です。
暑い...
更新日時 2003/08/03
内容 いきなり気温が上がったため、いろいろペースダウン中・・温度差には弱いなぁ。
寝苦しい毎日ですが、ふと「背中にヒートシンクつけたら、どれだけ涼しくなるのだろう」という バカアイデアが浮かびました。だれか商品化する勇者はいないものか・・(笑)。寝返りをうつと血まみれになりそうですが・・

開発している3Dツールのほうは、マテリアル部に突入です。 ゲームキャラクタ作成などが目的の1つでもありますので、UVオンリーでとりあえず考えてます。 (レンダラ自身は、投影マップ機能はつけているのですけどね)
で、3Dペイント機能もつけてしまおうかと。
・・・と文章を打ってるといきなりブルーバックになりました。暑さでマシンがいかれちゃったかな・・ 本日2度目のいきなりの落ちです(T_T)。
1回目は警告ダイアログが出て、シャットダウンのカウントダウンがいきなりはじまったのですが・・・ どうせいっちゅうねん(笑)。
・・・ってまた落ちた・・・3回目・・
FTPにアップする前にまた落ちる、で4回目・・・(T_T)。 どうも、Windows updateが悪さをしている模様。サービスから削除。これで安定かな?