2017年12月10日日曜日

メモ:SketchUpで面が切断される




 SketchUpを使っていると、上の画像のように、物が切断されて表示されてしまうことがある(時空が乱れた感じ)。
 根本的な解決方法は見つけていないが、とりあえず、ツールバーのカメラ→視野を選択し、視野角を狭くすれば多少改善する。
 ただしこの方法では遠近感が変化してしまうので、イメージ図を作ったりといった場合は、適切な視野角に戻すこと。


 根本的な原因は、3Dグラフィックでは、"最短撮影距離"と"最遠撮影距離"というものがある(名前は間違えてるかも)。最短撮影距離はカメラのレンズにもあるが、それとは全く別の問題。
 コンピューターグラフィックスでは、あまりに遠い物体は「遠すぎて見えないはずだ」という仮定に基づいて、描画処理を省略する。見えないものの色や影を計算したところでリソースの無駄だからね。
 同時に、あまりに近すぎる物体も、画面に表示しきれないし、ポリゴンの粗さが目立ったり、いろいろな理由により、描画を省略する。

 SketchUpの場合、最短撮影距離が長すぎるので、視点で物体に近づくと、物体の描画が省略されてしまう。視野角を変更すると、同じ範囲を描画するのでも、カメラの位置が変わり、視野角を狭くすれば、カメラを遠くに配置する必要があるから、最短撮影距離を相対的に縮めることができる。

 あまりにも視野角を小さくすると、パースペクティブが無くなり、平行投影に近づいていく。とりあえず、18度とか15度くらいがいいかな、という感じ。
 裏技?として、視野角を170とかにすれば、魚眼レンズで撮影したような感じになる。もちろん、時空の乱れはより悪化するが。

イージス艦のCICのスケール

USSTiconderoga(CG-47)CIC

 タイコンデロガ級イージス巡洋艦1番艦 CG-47"タイコンデロガ"のCICの写真。
 1984年3月1日、あるいは1984年3月13日17字29分撮影(前者はファイルの説明に書いてあった日付、後者はディスプレイに表示されている日時)。


 左から2番めのディスプレイ、AAW(対空戦闘)の状況表示だが、レンジは256NM(海里:ノーティカルマイル/Nautical Mile)と書いてある。
 レバノンで作戦行動中の写真だそうだ。
 ということで、ほい、レバノン周辺の衛星写真。


 黄色い円は、半径256海里の円。おおよそ、ディスプレイに表示された海岸線と一致している。
 ということで、RANGE SCALE 256NMというのは、「半径256NMの円に内接する正方形の範囲」(正方形:ディスプレイのアス比に依存?)という感じらしい。対角で512海里、辺方向で約360NMの範囲を表示している?


 表示されたアイコンは海軍戦術情報システム(NTDS: Naval Tactical Data System)に準拠しているが、wikipediaのアイコンとは違い、単色で表示されている。
 味方は円、的は辺が斜めな正方形、敵味方不明は辺が水平・垂直な正方形、中立は辺が水平・垂直な多角形、で表示される。
 海軍のシステムなので、洋上目標(船舶)が基準。船なら円形、航空目標なら円の上半分だけ、水中目標なら円の下半分だけ。ミサイルなら噴射炎っぽい記号が増えたり、ヘリコプターならローターっぽい記号が増えたり。魚雷は円形に水平線が追加される。魚雷は水中目標ではなく、水面目標の扱いになってる。地上目標はクロスで表され、仲間はずれ感がすごい。
 上の写真では、マップに水上目標や空中目標がいくつか書いてある。地上目標のアイコンもある。いくつかの空中目標は破線で表現されてるけど、どういう意味なんだろうか。
 ASWディスプレイでは、対潜戦なので水上だと思うんだけど、水上にも地上目標のアイコンが有る。あと円形の味方や正方形のアンノウン以外に、斜め四角の敵アイコンもいくつかある。

 ASWディスプレイはスケール64海里で、海岸線の形からして、左上はキプロス島の半島の付け根南側で、右下の線はレバノン南西部(中西部?)の海岸線と思われる。画面の中央部大部分は洋上で、画面の中心は34d8'N、34d24'Eあたりかな。
 左上の海岸線上から伸びる線は長さが25海里くらいかな?25海里/1分なら約2800km/h(1500kt)、25海里/5分なら約550km/h(300kt)、25海里/10分なら約280km/h(150kt)くらい。
 同じ画面の洋上目標は、最大で3分の1くらいの長さなので、それぞれ500kt、100kt、50ktくらいか。船舶と考えると、アーレイ・バーク級で最大30ktくらい、フリーダム球でも最大50ktくらいなので、80年台前半ということを考えると、もっと遅くても良さそう。となると、30分後として30km/h(16kt)とか、長いやつは90km/h(50kt)とか? でもたかが100km/hでこの長さだと、イージス艦のコンセプトだった、対艦ミサイルの迎撃とかをやろうとすると、線の長さはこの10倍くらいになってしまう。

 必要に応じて速度スケールは変更できるのかもしれないけど、それにしては速度の説明が書いてあるようには見えないし、そもそも頻繁に変更しては状況認識に問題がありそうだから、ちょっと考えづらい気がする。

 うーむ、謎は深まるばかり。。。

2段ベッド


 2x4材で下にテーブルの入ったベッドを作ろうと、いろいろ考えています。こういうのって正式名称はなんていうんだろう? 上下で寝るわけじゃないから2段ベッドじゃないし、空間的には3段分あるし。

 今使っているベッドも、形状は同じ感じですが、下側の空間がうまく活用できていません。ということで、まるっと作り変えてしまえ、と思い始めました。
 ということで、少し大きめの机にして、死蔵してる24インチを1枚出してきて、全体で3面ディスプレイにできないかな、と考えています。GTX950とGT520の計2枚差しだけど、3画面ってできるのかな? できたとしても、GeForceって1GPUでマルチディスプレイを組むと変なエラッタが出たはずだけど。
 探せばもう1枚くらいGT520出てくるはずなので、どうせWebブラウザやメディアプレイヤーくらいしか使わないから、PCI Ex x1でも問題ないと思ってますが。グラボ3枚差しかぁ。すげーな。内2枚はGT520だけど。


 SketchUp上で見ると、はしごがかなり邪魔っぽいですが、実際の位置関係で柱の横に座ってみると、あんまり気にならない感じです。顔から柱まで40cmくらいあるので、多少圧迫感があるかな、という程度。どうしても気になるなら、2ディスプレイにして余裕のある配置にしてもいいですし。

 寝る部分は、一応せん断応力を減らすような組み方にしています。すのこ状のフレームも上下に重なった形状にして、圧縮応力になるようにしています。が、youtubeの動画とか見てみると、みんなビスのせん断方向で作ってるんだよなぁ。意外とビスって高強度なのかもしれません。でも心配なので、やっぱり圧縮で作りたい感じです。
 四隅で圧縮ですが、すのこは2x4と2x6をそれぞれ2本ずつ縦で支えてるので、耐えれるはずです。本来は破壊試験とかして勘所を掴んだほうがいいんでしょうけど。
 一方で、はしご部分はビスのせん断だけで支えています。寝るところが落ちるとPCとか損失が大きいですが、はしごが壊れても自分が落ちるだけだし、はしごに乗ってるときはある程度即応でバランスを取れるだろう、という期待もあります。重心を考えると確実に自由落下で背骨から落ちるんですけどね。
 あとスノコは静荷重ですが、はしごは動荷重なので、はしごのほうが強度的には厳しいです。また外側に引っ張られる方向の荷重があるので、ちゃんと作るなら、踏み台が柱の向こう側になるように作るべきかな、という気もします。まぁ、それは壊れたときに考える、ということで。古いハシゴとか釘2本で止まってたりしますしね。多分そこまで気にすることじゃないんでしょう。


 SketchUpなので、日照のシミュレーションができます。今の案では、10月から4月あたりまで、モニタ上に日照があります。カーテン閉めるなりすれば多少は改善するでしょうし、イザとなれば黒い模造紙でも窓際においておけば、入射エネルギーは熱に変換しつつ、十分遮光できそうな気がしてるのと、それでもダメならアルミ蒸着シートを使えばいいだけなので、この部分はあまり気にしていません。
 それよりも、現状の窓際に机を配置していて、寒気が入ってくる、というほうが厳しいです。左右が板で囲まれ、窓際はサッシの隙間があって、直接足に気流が来る配置なので、かなり寒いです。


 ということで、目標は寒い時期に間に合うように作ることですが、どうなるかなぁ。
 材料はホーマックで買えますし、垂木でエアガンのターゲットを色々作ったときに買った卓上丸ノコがあるので、材料の切断も気軽にできます。
 ということで、ベッドを分解して搬出し、新しい材料を搬入して組み立てて、を1日でやりきる覚悟ができれば、いつでもできるはずですが、その気になるまでが大変だなぁ。
 一応、PCやHDDレコーダーも移動する予定ですが、これは現状の配置のままでもベッドを入れ替えるのはできるはずなので、そのあたりはあんまり心配していません。心配事があるといえば、3ディスプレイ化とかするとコンセントが圧倒的に足りない、というくらいでしょうか。ただでさえ古い家でテーブルタップ大量に使ってるのに。。。
 そういえば、小学生の頃は切り売りの電線と埋め込みのコンセントを買ってきて配線したりしてたので(どんな小学生だw)、ベッドにコンセントを大量に生やしてもいいんだな。机の天板はコンパネを使う予定ですが、奥の隅はディスプレイを斜めに置くので、デッドスペースになります。その部分に穴を開けて、コンセントを設置するとか。まぁ、法的な云々は置いておいて。。。


 上の図ではPCだけですが、他にもHDDレコーダやXbox 360を置かなければいけませんし、近いうちにXbox Oneも買う予定なので、そのスペースも作る必要があります。しかし机の上はかなり厳しい感じで、かと言ってスノコの下の空間を使おうにも、そこも厳しそうな気がしています。じゃぁ足元かというと、あんまり足に近いところに置くと蹴飛ばしそうで怖いです。
 あとせっかくなので、寝ながらにして手が届くような棚もほしいなぁとか、色々要求が増えています。

***

 まだ先の話ですが、中華CNCを買おうかと思っています。amazonで3万円くらいで売ってる、CNC2417とかですね。しかし、今はどこにも置くスペースが無いのと、買っても使うかなぁ、という心配が有って、かなり消極的です。
 でも、ベッドの下の空間を有効に使えるようになれば、空いたスペース(今PCを置いてる位置)にCNCを置けるくらいの空間は確保できるはずなので、そうなったら買いたいなぁって。

F-16風(続きのつづき)


 とりあえずジンバルのコントローラを作っています。
 いちおうTLE(人工衛星)とHIP(恒星)のボタンがありますが、HIPは未実装です。

 MENUを押せばメニューページになり、天球表示以外にコンフィグ画面があります。コンフィグは今のところシリアルポートの接続/切断だけです。ポートの選択とかは別のタブに作っています。

 TLEをONにすると、直下にあるテキストファイルに入っているすべての衛星が表示されます。今のところ1800個ほどでしょうか。1800個のTLEの 位置計算、方位仰角計算、Graphicsへの書き込み、をやっても、10-25msecくらいしかかかりません。衛星1個あたり10マイクロ秒で計算してる、ということでしょうか。確かに衛星の計算って複雑なだけで計算量は多くないんだけど、いくらなんでも早すぎでしょ。ARMだと、計算だけでも1msecかかるのに。

 天球全体で見てみると、静止軌道がかなり濃い感じです。しかし、東側は太平洋上なので、静止衛星は少ないですね。

 ディスプレイにマウスカーソルを重ねると、一番近い衛星の名前が表示されるようになっています(左側のディスプレイにカーソルを重ねています)。
 今のところ、ディスプレイをクリックすれば、無条件にジンバルがその方向を向きます。本来であれば、マニュアル操作ならジンバル指向、TLEモードなら衛星を選択して継続追尾、HIPモードなら恒星を選択して継続追尾、みたいな感じにするべきでしょう。


 衛星1800個ならテキストファイルでも500KiB未満ですから、SDカードに楽勝で入ります。HIPカタログもテキストデータですが、恒星約12万個分でも容量は50MB程度です。SDカードに余裕ですね。
 TLEの計算自体はマイコンでできることも確認済みなので、スタンドアロン動作は問題ないはずです。恒星位置の計算はマイコンではしたことないですが、あまり計算量は多くないですし、衛星ほど素早く動くわけでもないので、なんとかなるでしょう。


 TLEは、一応、データ長は固定ですが、衛星番号は間欠なので、衛星番号から直接ファイル位置を計算することができません。一番簡単なのは、TLEフォルダに、TLE1個毎に衛星番号をファイル名にしたファイルを1個ずつを作る、という感じになると思います。FAT16なら6万個くらいファイルを作れるらしいので、デブリとかを除けば、十分収納できます。

 HIPは空白埋めの固定長なので、特定のデータを取り出すのはそれほど大変ではないはずです。HIPもやはり間欠データですが、12万セットに対して100セット程度の不足なので、HIP番号を受け取って、目的のデータが来るまでファイルの前方にシーク、という程度でも問題ないはずです。もしそれが許容できないなら、ヌル行を追加したテキストファイルを作ればいいだけですし。


 ということで、なんとなくコントロールソフトも見た目はちゃんとしてきました。でも、かなり面倒です。
 最初は「参照渡しだから1個作れば複数の表示ができるね!」と思ってたんですが、その方法では、片方でズームするともう一方もズームする、という感じで、かなり使いづらいです。一応、表示内容は別々に選べるので、それだけが救いです。
 しょうがないので、ディスプレイごとにインスタンスを作って、別々にズーム・移動ができるようにしましたが、個別に登録しなければいけないし、UIハンドラも個別に作る必要があるので、面倒です。

 あと、MFDからペイントイベントを受け取ったら、現在表示中の画面のレンダーを呼び出して、そのレンダーは表示内容に応じて下位レイヤーのレンダーを呼び出して、という感じになっています。
 下位レイヤーでは、例えば天球レンダーからTLEレンダーを呼び出した場合、衛星位置は天球レンダーの表示位置に応じて衛星位置も表示することになります。しかし、天球を拡大しても、フォントは拡大されずに常に同じ大きさで表示する必要があります。さもなくば、天球を拡大すると、衛星名が画面の外に飛び出してしまいます。これは衛星のアイコンも同じで、ズームしても衛星のシンボルは一定の大きさで表示されたほうが便利です。
 ということで、衛星の位置を表示する際は上位レイヤーの座標変換行列を使い、衛星の名前を表示するときはスケールが違う行列を作り、という動作が必要で、しかも衛星の情報(軌道高度とか)は画面の左上とかに固定されたほうが読みやすいでしょうから、そういう表示は新しく行列を作って、という感じの処理を、都度書く必要があります。
 これがかなり手間なので、もっとスマートな方法を使いたいのですが、なかなかいい方法が思いつきません。

 こういう処理は、例えばUnityの3Dゲームが近いかな、という気がしています。ゲームフィールドは3Dで表示し、キャラの名前等は相対位置で2D表示し、ステータス等は絶対値で表示し、という感じで。
 ということで、ゲーム制作関係の参考書とかを読めばいいのかな、とも思ったりしますが、多分Unityは抽象化しすぎて参考にならないでしょうから、ゲームエンジンを作るような本が必要なのかな。


 そういえば、F-15ってASAT兵器を使えるけど、MFDに衛星を一覧表示したりするんだろうか?イージス艦もやはり対衛星ミッションを行っているから、衛星の表示もできるはずです。
 F-15の場合は、飛行前に地上で目的の軌道を入力して、飛行時はそれ以外の物は表示されないようなインターフェースになってるはずです。ASATの試験はF-15Aで行われましたが、一人乗りで操縦しながら衛星を選択するとかは大変ですし、そもそもF-15Aに気が利いた表示ができるシステムを載せれるとも思えないし。

 イージス艦の場合は、NTDSのアイコンで目標の速度や移動方向がわかるようになっていますが、低速なヘリコプター等も表示することを考えると、同じスケールでマッハ25とかを表示すると、速度スケールが画面外に出てしまい、かえって速度がわからなくなってしまいます。低速な目標から超音速ミサイルまでを表示したりすることを考えると、速度スケールは対数スケールかな、という気もしますが、常識的に考えれば、こういう表示は「何分後の未来位置まで引いた直線」とかでしょうから、やはり対数スケールってことは無いでしょう。
 例えば5分後の未来位置なら、ISSの場合は5分で日本列島縦断するかしないかくらいなので、1画面で日本を端から端まで表示できるイージス艦のディスプレイなら、衛星も十分に表示できそうな気がします。
 特に弾道ミサイルを追尾できるイージス艦では、ミサイルの現在位置、落着予想地点、迎撃までの猶予、といった情報を表示する必要があるので、少なくともBMDの際の意思決定が問題なく行えるくらいの表示はできるはずです(って、何日か前にもこんな話書いたな)。

 イージスのCICで衛星がどのように表示されるかなんて、わざわざ隠すことでもないでしょうが、かと言って、わざわざ表に出すことでもないでしょうから、当分は見れないだろうなぁ。最近だとICBMとか色々で、イージスで宇宙空間見ることも多いだろうし、センシティブな話題だろうからなぁ。

2017年12月8日金曜日

F-16風(続き)


 24インチFHD(本物の3割増しの大きさ)でスイッチを押してみたけど、意外と押しづらかったのでボタンを大型化したのが前回からの見た目の違いかな。前回はclassだったけど、UserControlになってたり、いろいろ変わってるのだが。

 ボタンの表示や操作内容はContextMenuStripで渡すが、C#は参照渡しなので、複数のパネルで同じ内容を表示できる。1箇所でも違う内容を表示したいなら面倒だけど。
 本物のF-16等でも、左右のMFDで全く同じ内容を表示できるので、複数のパネルで操作できるのは実物準拠という感じ。実機の場合は、もし片方が壊れても大丈夫なように、万が一片方が被弾しても大丈夫なように、という事なんであろう。

 ただし、片方のpaintイベントがもう片方に波及しないので、片方でCheckedを変えたりしても、もう片方は反映されない。paintハンドラでもう片方をrefreshすると、無限ループになってしまうので、うまいやり方を考えないと。
 現実的には、ディスプレイの内容は20fpsとか30fpsで書き換えることになるだろうから、タイマで定期的にrefreshすれば無問題、という気がする。

 1280x800のノートPCでは、ディスプレイを2面表示することは可能。
 左右で別の情報を表示するようなインターフェースにしてもいいし、片方を情報表示、片方をコンフィグページ、みたいにしてもいい。

 ジンバルのコントロールパネルを作ってるが、マニュアル操作をどうするかが問題になってる。アナログ入力があればいいんだが、C#で簡単に使えるアナログUIは意外と少ない。Xbox360のコントローラであればXNA経由で使えるが、すでに入手性が悪くなってる。Xbox oneもXNAから扱えるんだろうか?
 一応C#でもジョイスティック等は読み出せるが、製品によってボタンやスティックの割当が違うから、このあたりをうまく吸収してくれるように作る必要がある。


 さっき、一瞬、F-15のディスプレイも調べてみたが、あまり良くわからなかった。
 F-15A/B/C/Dはいかにもなアナログ計器のコックピットだが、F-15Eではグラスコックピット化されている。
 EF(E型フロント席)はMFD3面と、HUD下に6行キャラクタディスプレイがある。ER(E型リア席)はMFD4面と、右側に小さなパネルがあるらしい。ERは兵装士官(WSO: Weapon Systems Officer)が乗るが、戦闘機とは思えないくらい簡素化されてる感じ。操縦桿があるのが飛行機らしい点。もっとも、F-35は電源OFFならのっぺらぼうだが、アレは「そういうもの」という思い込みがあるし。

 F-15の操縦桿には親指で操作する「キャッスルスイッチ」という物がある。滑らないようにする突起が、西洋の城の見張り台(身を隠す突起があるやつ)に似ているから、「キャッスル」スイッチと言うんだそうだ。
 ゲーム用のジョイスティックでは、ここにはPoVスイッチ(あるいはハットスイッチ)と呼ばれるスイッチが付いていて、主に視点操作に使われる。これは基本的に「開放」と「操作」の2値を受け付ける(開放と8方向で9値?)。
 F-15では、これはFLIRの視線方向操作に使うらしい。ということでゲームと同じく視点操作なのだが、ON/OFFで望遠のFLIRを操作するのは大変だろうから、おそらくアナログ入力になっているはず。
 一方で、操縦桿にはハットスイッチみたいなスイッチがもう一つ有って、これはトリムの調整に使われるらしい。これはアナログ入力が必要なほど敏感じゃないはずだから、2値(9値?)で足りるはず。


 ジンバルの操作でも、やはりアナログ入力がほしいのだけど、どうやって作るかなぁ。
 スタンドアロン重視ならマイコンにジョイスティックを追加すればいいんだけど、PS2のコントローラに入ってるようなやつでは気分が出ないし、かと言って工業用のタイプになると値段が2桁上がってしまう。
 F4ならUSBホストもハードウェアでできるけど、USBを実装するのはとても面倒くさい。気がする(USBって使ったこと無いので不明)。
 適当なUSBジョイスティックのXYをC#で読めばいいじゃないか、とも思うけど、せっかくジョイスティックを使うならHOTASっぽくしたい。スロットルデバイスは持ってないから、HOSになっちゃうけど。

 他の方法としては、JHMCS風の「見た方に向く」とか、短SAM風の「覗いた方に向く」とかもあるけど、どちらも作るのは面倒そう。

 当面は、MFDで「アナログモード」みたいな設定を作って、それがtrueのときにMFD上を左クリックしたままドラッグしたりすれば、それが入力になる、みたいな感じかなぁ。
 PC画面なら本物のMFDと違って、画面座標の直接入力が可能だけど、あんまり多用しすぎるとプログラムが大変になる。
 これはF-35でも同様なはず。もっとも、F-35は振動や加速度の条件が厳しい戦闘機のシステムだから、「振動で指が動いてしまった」とかで誤った入力にならないように、フリックやらスワイプやらの操作は無いらしい。ということで、画面をタッチした座標と、単押しか長押しか、くらいの判定しか無いはず。

 暖かくなるまでに動くようになればいいから、とか余裕かましてたけど、大変そうだ。

2017年12月7日木曜日

F-16風の


 F-16のMulti Function Displayっぽい画面をC#で作ってみました。もちろんボタンは操作可能です。


 F-16のMDFを調べてみると、Honeywellの表紙含めて4p分くらいのPDFが出てきました。日付は2006年になっています。

 F-16A/Bではコックピットにはレーダー/HUDレピータのディスプレイが1基と、兵装用の9セグ(12セグ?)LEDx5行のディスプレイが使用されているようです。
 F-16C/D(Block 25)では単色のディスプレイ2枚に置き換わり、多用途化されたようです。さらにBlock 5xではこれが多色化されたようです。
 UAEに輸出されたF-16E/F(Block 6x)では大型のカラータッチ液晶を搭載したようですが、写真を見つけられませんでした。大型タッチ液晶というと、同じロッキード・マーティンのF-35が思い浮かびますが、おそらく同じようなものだと思います。


 先のカタログはカラーMFDのものですが、解像度は480x480pxで4x4インチだそうです。密度的には、24インチFHDの3割増し、18.5インチFHDや13.3インチWXGAくらいです。11年に買ったノートPCが13.3インチWXGAなので、民間の普及品よりちょっと高密度、くらいでしょうか。
 ただしコントラスト比は航空機用だけあり高く、5750対1らしいです(読み間違えてるかも)。また輝度も非常に高く、約790cd/m^2だそうです。参考までに、この間買った4k液晶(HDR非対応)は300cd/m^2でした。
 また、戦闘機では夜間はナイトビジョンゴーグルを使用しますが、新月の星明りだけで敵の戦闘機を見つけれるくらいの高感度なものですから、直接高輝度な画面を見てしまっては簡単にリミッターが働いてしまいます。なので、バックライトにも相当なダイナミックレンジがあると思われます。カタログにも「under all lighting conditions, from night-vision goggles to full sunlight」と書いてあります。簡単に訳せば、「直射日光から暗視装置まで、どのような光環境でも」みたいな感じでしょうか。

 液晶の起動には1分@-20℃と、ちょっと時間がかかります。とはいえ、ウチの液晶でも冬に1日家を開けて室温が10℃を下回ってしまうと、自己発熱でコントラストが正しくなるまではしばらくかかりますから、-20℃で1分というのはかなり優秀かもしれません。ヒーターでも入ってるのかな。

 この液晶は13ポンド(約6kg)のモジュールですが、映像を生成するシステムが他に必要になるようです。映像を生成するモジュールは31ポンド(約14kg)で、メインのシステムにはPowerPCベースのカスタムCPUが使われているようです。クロックは400MHz、メモリは4MB(8MBまで増設可能)、バッテリーバックアップされた64MBのメモリ(オプション)、といった感じで、更にグラフィック用に240MHzのPowerPCが乗っていて、こちらは32MBのRAMと16MBのFlash、16MBのテクスチャメモリと15MBのフレームメモリが乗っているそうです。
 メインの計算モジュールより描画モジュールのほうがメモリが大きいあたり、グラフィックの負荷がいかに高いかが伺えます。
 この描画モジュールはC言語で開発されているようです(C言語で開発可能、の意?)。メインシステムはJOVIALとCだそうです。JOVIALは聞いたことも無かったのですが、F-15やC-130、F-117等、かなりいろいろ使われているようです(wikipediaで、プラットホームに、other legacy systemsと書いてあって笑ってしまった)。

 このシステム、5GB(拡張可能)のストレージを持っており、航空機に搭載したままで書き換えが可能なようです(地上で整備士が書き換える、くらいの意味でしょう)。

 地図の倍率は125万分の1と50万分の1の2段階を選べるようです。125万分で127km四方、50万分で約51km四方、くらいの範囲を表示できます。125万分は巡航で9分、50万分は同4分くらいの距離でしょうか。50万分では1pxあたり100mくらいですから、遷音速なら1秒に3ピクセルくらいの分解能です。
 CASに使うには50万分では荒いし、洋上に出て迎撃するには125万分でも狭いし、みたいなとても使いづらそうな気がしますが、そもそもF-16のコンセプトからすれば、これくらいでも問題ないのでしょう。
 表示モードは北が上、ヘディングが上の両方を選べるようです。

 インターフェースはNTSCといった身近な物がある反面、MIL-STD-1553が5本入力可能だったりと、軍用な面もあります。また、イーサーネット100BaseTでデータ通信ができたり、デバッグ用に10BaseTが付いてたりもするそうです。

 他にも、画像をアップロード/ダウンロードする機能があったり、地形を3Dレンダリングで表示できたり、といった機能もあるそうです。


 興味本位で見つけたペラッペラなパンフレットくらいのPDFですが、真面目に読んでみるといろいろおもしろいですね。

***

 さて、一番最初のC#のヤツですが、コントロールではなく、クラスとして作っています(後から気づきましたが、これはコントロールとして作るべきでした)。
 コンストラクタにはContextMenuStripを与えており、ボタンで操作できる項目はVisualStudioのGUIで編集可能です。
 もちろん項目のボタンを押せばその下の階層に移動できますし、上に戻るタグを付けておけば勝手に階層を遡ってくれます。
 今のところ、ボタンの数(20個)以上の項目が有った際は、それ以上は表示しない、という挙動です。ContextMenuStripは動的に生成可能ですが、動的に作って20個超えても知らないよ、というスタンスです。
 クラスの中でClickハンドラを追加して移動していますが、もちろん外部でClickを登録しておけば、それに応じて処理もできます。
 またMDFの描画イベントを外にも出しているので、必要に応じて外部で描画できます。同時に現在選択しているToolStripMenuItemも参照できるので、外部はそれに応じて描画内容を変更する、という動作にしています。

 もともとは気分転換に作り始めたGUIですが、タッチ液晶で使えば意外と便利そうな気がします。
  もうちょっと色々使いやすいようにして、FSXの情報を表示したり、ジンバルの制御ソフトに組み込んでも面白いかな、と思っています。


追伸
 Arma3でマップに使えるアイコンみたいなやつ、MIL-STD-2525Bという規格らしい。2013年にオープンソースとして開放された模様。

 Test Multipointをクリックするとアイコンが表示される。

2017年12月6日水曜日

星座の境界

 星座(天球を88分割した領域)の境界線データ。

 IAU(国際天文学連合)のページに有る。
 The Constellations | IAU
 Charts and tablesにTXTというリンクがあるが、これに境界線の赤経赤緯の点がリストになっている。

 図にするとこんな感じになった。


まぁだいたいこんなもんかな、という感じなので、大きく外してはいないはず。
 最初は4等星より明るい星を表示してたけど、6時/20度の領域に1個も星がなかったので、4.5等星以上に変更した。この領域ってこんなに星が少ないところなのかな。

 それにしてもこの分割、怪しい古代文明の遺跡にある扉の鍵みたいな感じだ。88個のカケラを集めなければ入れないボス部屋、とか。

 星座の星をつなぐ線のリストとかもほしいけど、どこにあるんだろう。プラネタリウムソフトによって表示が違うので、統一したデータとかはないのかもしれないけど。