---

前回 から2週間、描き始めてからだと既に2ヶ月。2週間前にあとは微調整かと思ってたのですが、その微調整が結構多いかつ分かっているだけでもまだ数箇所修正したい。我乍ら2Dでも3Dでも描くのが遅いw

あんまり細かい所をちまちま直していても息が詰まるので、ジェット戦闘機がよく出す翼端の雲を付けて気分を盛り上げようかと。当初はGIMPなど2Dグラフィックエディタで後から描き足そうかなと思ってたのですが、調べてみるとBlender でも雲が描けるらしい。

ここ を参考に雲のオブジェクトを追加。端に黒点ができるなど修正が必要なものの、なかなかいい感じです。が、大量のメッシュを作った上にレイトレーシングしているためか、雲を追加しただけで一挙にソフトの動作が重く(通常の設定変更が数秒かかる、レンダリングが1秒以下から20秒に)なってしまいましたorz

雲オブジェクトを別のレイヤーに置いて非表示にしておけばそれほど支障はないのでこの方法をやめる気はないのですが、背景にもっと大きな雲を描いたら更に遅いだろうな。ガムバレCore i7(注: 第1世代)。

[参考]

• Creating Volumetric Clouds (Blender Guru)
• Blender 2.5用の雲の風景をすばやくモデリングするチュートリアル (Blender.jp)

---

ラプター 、ひとまずモデリング完了。後々微調整は必要になってくるでしょう。

主翼より下は平面が多いから楽かなと思ってましたが、こちらも甘かった。特に吸気口と排気口辺りがそれ自体複雑な曲面な上、隣接する胴体・主翼・尾翼が平面主体なためつなぎの部分に手間取りました。

吸気口周りとその横の胴体(操縦席部分)の間の隙間に至っては資料が手に入らなかったため、実物がどうなっているか不明。結局何もメッシュを貼ってないため正面からみると胴体内部まで吹き抜ける穴となっております。正面からの構図には使わないようにしようw

またあまり目立たない細部にこだわってしまい、メッシュが多くなってしまったのも時間がかかった理由。手の抜き方も覚えないといけないだろうなぁ。

次は着色(マテリアル設定)ですが、しばらくプラモデルを愛でるが如く、いろいろな方向から眺めて楽しもうかな。

[2011/8/1 追記] 続き

---

久々に3DCGを描く気になりました。前回描いたのは3年前 。ほぼ完全に忘れてしまったため、一からBlender操作を覚えなおしです。

前回よりも複雑なモデルに挑戦ということで、戦闘機F-22ラプターを選択。ステルス機はステルス性能を高める目的で機体を平面で構成する傾向があるため、比較的楽に描けるかなと思ったのですが甘かった。いざ描いてみると平面が多いのは胴体下部くらいで、多くの部分は他のジェット戦闘機にも見られるような流線型。これが飛行機かというほど平面で構成されたF-117 にしておけば良かったなｗ

最初の一週間は下絵の用意、それから一ヶ月かかってようやく機体上面が出来上がり(と思ったら、垂直尾翼の根元に要修正箇所発見)。残る機体下面は比較的平面で構成されているので楽そうな感じがするのですが、ネットを探しても下絵に出来るような真下正面からという画像が入手しづらく、上面よりも勘でモデリングしなければならない箇所が多そう。その後色付け・照明設定と、まだまだ時間がかかりそうです。

[2011/7/16 追記] 続き

以前書いた.NET Remotingでの双方向通信 、サーバ側からクライアントにイベントを飛ばすという形で逆方向通信を行うものでした。

そこではクライアント側にあるイベントハンドラには[Oneway]修飾子を付けるように書いたのですが、実は意味が分かっていませんでした。文字通り一方通行であるということを指示するものでして、呼び出し側には返値・例外が返ってきません。まぁイベントですから返り値を求めることも少ないでしょうし、多くの場合では付けて問題ないかと。

余談。返り値のあるイベントハンドラを作ると最後に実行された(最後に追加された?)イベントハンドラの返り値がイベント発信側に渡るようです。 [参考] C# - 複数のイベントハンドラをセットしたメソッドを呼び出したときの戻り値 (おのでら氏)

ただ副作用あり。イベントハンドラが呼び出される前にサーバ側は次の処理にかかるようです。イベントが受け取られなくてもエラーを出しても知らん振りなのですから、次の処理にすぐさまかかった方がサーバ側のパフォーマンスは上がる。実際のイベントを.NET Remoting越しに処理するのは別のスレッド、おそらくスレッドプールに任されるのでしょう。

ここで短時間にたくさんのイベントを発信すると、イベントハンドラが呼び出される順番が変わることがありえると分かったのが昨日。スレッドプールのキューには順番通りに入っているのでしょうが、実行中に追い越しが発生すると思ってます。

[Oneway]と外すと全てのイベントハンドラが処理を終えるまで次の処理に進まないため、イベント発信を単一スレッドにやらせている限りは順番が入れ替わるということは防げます(受信終わるまで次のイベントが発信できない)。

ただしサーバ側パフォーマンスは落ちるでしょうし、クライアント側が死んでしまった場合サーバは延々と返り値を待つことになりますので、

• クライアント側は受信したらすぐに処理を返して、実際の処理はバックグラウンドで行う
• サーバ側はイベント発信処理をタイムアウト付き非同期処理する

などの対策が要るでしょう。[Oneway]付けとけばやってくれる非同期処理を自分でやることになる…

---

OpenVPNを使って出先から自宅へアクセスするときの設定。

• 基本的にはOpenVPN 2 HOWTO 日本語訳 通りに進める
• IPアドレス
• 出先からアクセスしたい自宅マシンたちには固定IPアドレスを割り当てる。必須ではないがDHCPだとかなり面倒になる。
• 自宅と出先で異なるアドレス空間にする。でないと出先で192.168.0.cにアクセスしようとしても、出先ルータ直下の192.168.0.cへアクセスを試み、VPNが使用されない。
• 自宅ルータが出先と同じアドレス空間を張っていてもよい。自宅マシンたちが出先とはかぶらないアドレス空間に属するIPアドレスを持っていればよい。図のように各マシンに複数のIPアドレスを割り当てるのがひとつの方法。
• 自宅ルータの設定
• 外部からのOpenVPN接続に対してOpenVPNサーバの適切なポート(通常1194)へフォワードする。
• インターネット側のIPアドレス(my.global.ip.address)が固定で無い場合は、DDNSサービスなどを使用する。
• 自宅OpenVPNサーバの設定
• ファイアーウォールがOpenVPNの受信を妨げないように設定する。
• Server系以外のWindows (XP, Vista, 7など)はIPルーティングを有効にする 。具体的にはレジストリHKEY_LOCAL_MACHINE のSYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters¥IPEnableRouterの値を1にしてWindows再起動。これをやらないとOpenVPNサーバ(10.8.0.1)にしかアクセスできなくなる。
• OpenVPNサーバ設定ファイル
• push "route 192.168.1.0 255.255.255.0"を設定することで、自宅の192.168.1.0/24のマシンたちにアクセス可能。

port 1194
proto tcp
dev tun
dev-node Tap1
ca ca.crt
cert myhome.crt
key myhome.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

• OpenVPNクライアント設定ファイル

client
dev tun
proto tcp
remote myhome.global.ip.address 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert mycert.crt
key myhome.key
comp-lzo
verb 3