伊能図にみる佐世保

inoh0190-trimmed

伊能忠敬が作成した「大日本沿海輿地全図」、通称「伊能図」に掲載されている19世紀初頭の佐世保市の地図です。分かりやすいように着色をしていますが、今からちょうど200年前の地図とは思えないほど正確ですね。

佐世保市民の方ならご存知の方も多いと思いますが、明治時代に佐世保に鎮守府が置かれるまで、佐世保は小さな漁村でした。そのため、明治より前の佐世保に関する史料は他の大きな街に比べれば乏しいようで、今なお研究が進められています。

白形浦

佐世保の人に「白形浦」と言っても誰もピンと来ないと思います。位置的に考えると鎮守府施設が置かれた場所のため、後世に地名が残らなかったと思われます。港湾設備を整えるために、明治初期に測量した図が実家にあったはずなので、今度帰った際に確認したいと思います。

横尾

今では影が薄い横尾町ですが、佐世保が市になるずっと昔からあったようです。私の家系の本家と分家は、横尾町一帯にあるので、市になる前から住んでいた一族なのかもしれません。だったらちょっと嬉しいな。(ほとんどの佐世保市民は、明治以降に佐賀などから移住してきた方々らしいです。)

山中

現在の山の田浄水場付近が「山中」という地名になっています。桜木町、赤木町付近だと思いますが、山中山という地名までありますね。浄水場が作られたのは1908年(明治42年)なので、その頃には山の田と呼ばれるようになっていた模様です。

早岐

早岐の古い町並みを見ると分かると思いますが、昔は早岐のほうが都会でした。江戸時代には既に100軒を越える集落があったらしく、平戸方面・長崎方面・太宰府といった福岡方面、さらには海路へとつながる地理的な理由もあったと思われます。400年続く早岐茶市がその繁栄っぷりを物語っているのではないでしょうか。また、早岐の名前の由来ともなった速来津姫伝説が収録されている「肥前国風土記」にも登場しています。

相神浦

最近、離島防衛の要となる「水陸機動団(日本版海兵隊)」が陸上自衛隊相浦駐屯地に拠点を置くことになりました。その基地がある相浦一帯は、以前は相神浦(あいこのうら)と呼ばれていたようです。相浦川流域全体のようで、柚木までカバーしています。佐世保村との境界は、今の春日町、西海学園近くにある堺木バス停留所付近だったらしく、松浦郡と彼杵郡の境界にもなっていたようです。 地図では小さくて分かりづらいかもしれませんが、愛宕山付近に飯盛城のことだと思われる「古城跡」の記載も見てとれます。

こういう風に地図を眺めているだけでも楽しいので、時間ができたら市立図書館の郷土資料室に行っていろいろと調べてみたいです。

ASP.NET を初体験

Web アプリケーションといえばもっぱら Perl, Ruby, Python あと少しだけ PHP な自分なのですが、仕事でちょっとした ASP ベースの API を書かなければならなくなりました。うちは90年代に育った小さな会社ということもあり、ネットワークは Windows ドメインネットワーク、Web サーバーも IIS ベースという(自分にとっては)息が詰まるような環境です。

ASP が書けるプログラマーがほとんどいない状況で、ASP ベースの API を担当していた先輩が事故で入院してしまい、その後釜を任された同僚のサポートという形で扱うことになりました。元々の API は無印の ASP ですので、いわゆる Visual Basic 6 的な構文。仕事の内容なので、あまり具体的には書きませんが、90年代半ばの機能を駆使してわざわざ面倒かつ煩雑なシステムにしてしまっているように思えて仕方ありません。UNIX における枯れた技術と Microsoft の政略が絡んだ枯れた技術では意味が違うと思いました・・・。

IIS の意味が分からない

Apache, lighttpd, nginx などの Web サーバーの考え方がベースになっている自分にとって、Microsoft の Web サーバー Internet Information Service の意味が分かりませんでした。実装した API の不具合がスクリプトサイドにあるのか、Web サーバーにあるのか、DB サーバーにあるのか、構造から理解するのに苦しみました。UNIX 生まれのインターネット技術をパクった挙句、ユーザーのためではなく自分らのために無駄なものをたくさん乗っけて、挙句、複雑怪奇な環境を提供しているようにしか思えません。Microsoft が出している開発環境をお金を出して買えば、トータルで面倒を見てくれるように商売戦略上設計されているんでしょうが、非 Web 環境で毎日 Visual Studio を使っている UNIX ユーザーとしてみれば、それも眉唾ものだと思いました。

Visual Studio の意味が分からない

Microsoft が提供している環境というのは往々にして、「ユーザーが自分でモノを考えて何かをやろうとすると墓穴を掘る」みたいなので、大人しく Visual Studio の Web デベロッパーツールを使用することにしました。うちは VS2008 ベースですので必然的に ASP.NET になります。Microsoft の技術にコードを投入してしまうと、過去の遺産とかそういうものは諦めないといけません。 VS2008 をインストールした時点で、まさか ASP.NET をすることになるとは思ってもいなかったので、追加インストールが必要になりました。追加インストールのためインストーラを起動してみると、嫌がらせのようにインストーラがエラーで落ちます。私の環境には、VS2010 と 2013 も入っているのですが、それが影響しているんでしょうか・・・。調べる手口もありません。 オープンソースなソフトウェアならば、調べてバグレポートのひとつも送らねば!と思うのですが、お金を払った上にこれだとそんなにマゾにもなれません。さっさと諦めてしまいました。

オープンソースの .NET 環境 Mono が素晴しい

平日、家に帰った後と休日はもっぱら Linux ベースで作業しています。職場では Windows と Visual Studio を使っています。どちらも時間的には半々なので、自身では盲目的な信者のつもりはないのですが、やっぱりオープンソースの方がユーザーフレンドリーです。

自宅の Linux 環境にも Mono を入れているので、もしかしたら ASP.NET も Linux 上で上手い具合に開発ができるのかなーなんて思って調べてみると、やはりありました。オープンソース万歳!信者とでも何とでも言ってくれ!

aspnet_on_monodevelop

Mono Develop にも最初から ASP.NET ソリューションを作成するのがついてました。もう「これでいいじゃん」感がハンパないです。さて、実際に開発をするには ASP.NET を動かすための Web サーバーを導入する必要がありますが、これも Mono 開発環境の一つとして XPS サーバーが準備されています。こいつも例のごとく、コマンド一つで導入できるのがクールです。

sudo aptitude install mono-xsp

Mono Develop のサンプルの ASP.NET ソリューションをデバッグ実行すると、次のようにちゃんと動きました。ハラショー。

asp_net_running

互換性についても C# は確か ECMA だか ISO だかで規格化されていますし、Visual Studio や IIS といった環境に左右されまくる Windows ベースでの開発よりもよっぽど安心して出来そうです。ちなみに、うちの環境では .NET は 4.0、C# は ISO-2 までサポートされています。

mono40

MonoDevelop が Vi キーバインドできるようになって、C++/CLI を使わずに済むプロジェクトをやるようになったら、本気で MonoDevelop で仕事しようと思いました。

追記

デフォルトで Vi キーバインドできました。快適すぎて涙が出てきそうです。

WordPress の記事投稿を Markdown に変更しました。

タイトルのとおり、WordPress の記事投稿を WP-Markdown というプラグインを入れて Markdown に変更しました。HTML のビジュアルエディタだと、コード中の <> 記号との相性が悪かったり、ドキュメントの文字情報とレイアウト情報がごちゃごちゃになってしまう HTML というものの、情報の入れ物としての素質的にどうなのかなあ、と思うところがあっての変更です。

シンタックスハイライターと衝突

これまで、コードのシンタックスハイライトには「SyntaxHighlighter Evolved」というプラグインを利用していましたが、Markdown プラグインと相性が悪いのか、レイアウトが崩れてしまいました。 現在は SyntaxHighlighter Evolved を無効にして、WP-Markdown の pretify syntax highlighter を有効にしています。これは pretify.js というライブラリでハイライトしてくれるらしいモノで、SyntaxHighlighter Evolved のように行番号表示や言語を指定する機能はありませんが、軽快かつ適当に色をつけてくれます。

なお、wp-markdown-syntaxhighlighter というプラグインを入れれば SyntaxHighlighter Evolved との衝突を防げるといった記事を見かけましたが、自分の環境ではムリでした。

LXC のウェブインターフェイス「LXC Web Panel」を使う

LXC Web Panel を去年の10月くらいにインストールしたのですが、早速忘れかけていたので覚え書きしておきます。

LXC Web Panel は AWS の EC2 のように WWW ブラウザから LXC コンテナを制御できるインターフェイスです。英語ですが、ごちゃごちゃとしておらずシンプルで使いやすいものになっています。

インストール

Github のページからインストールスクリプトをダウンロードして bash に食わせるだけで OK です。

wget http://lxc-webpanel.github.io/tools/install.sh -O - | bash

Python の Flask と Bootstrap で書かれているようです。もしかすると python-dev パッケージが必要かも。公式ページのインストールマニュアルを参考にしてください。

FAQ に

Can i use LXC Web Panel on Debian?

  • Nope, sorry… It doesn’t work :(

と書いてありましたが、さくらの VPS 上に作ってる Debian サーバにもインストールできました。しかし、公式サポートはあくまでも Ubuntu のようですので、自己責任で。

使う

インストールが成功すると 5000 番ポートでリスンします。WWW ブラウザで開きます。

firefox http://example.com:5000/

ログイン画面が出てきます。ユーザー名「admin」、パスワード「admin」で入れます。ログインできたら、http://example.com:5000/lwp/users でパスワードを変更しておきましょう。

lxc-web-panel

あとは見てのとおりです。必要な時にスマートにインスタンスを作ったり動かしたりできるので、いろいろとはかどりますね!

このウェブインターフェイス以前の問題ですが、ホストが Debian の場合、LXC の設定ファイルをちょっと工夫してあげなければならないので、新しいコンテナを作成する時にはシェルからコマンドを叩いているのが現実ですが、個人ユースでももっともっと VM を使うことが一般化してきたら、設定の煩雑さも解消していくと思われます。(他力本願)

ユーザごとにリソースを切り分けたりできるようになると、EC2 のようなサービスも個人でできそうですね!

参考リンク

書いた後で気付きましたが、Qiita でもっとスマートにまとめている方がいらっしゃいました。

シェルスクリプトでCGIチャットを書いてみました。

CGIは、標準入出力と環境変数を用いて動的コンテンツを生成する仕組みなので、これらを扱うことができるプログラムだったら記述言語は問いません。CGIと言えば「CGI/Perl」の組み合わせだけが突出して有名ですが、CGI/Cだって世の中にはたくさんあります。 さらに極端な事を言えば、CGI/awkだってCGI/shだって不可能ではありません。

ただし、CGI/shといったものは少なくとも私の知る限りでは、現在推奨はされていません。 Webインタフェイスとして動作するためのセキュリティを高めることに対する煩雑さであったり、大量のリクエストを効率的に捌くための本質的な性能であったり様々でしょうが、わざわざシェルスクリプトを引っ張り出してこなくても、Perl や Ruby、Python と言った気の利いた高級言語が使える環境が整っていることがほとんどでしょう。

じゃあ何故 CGI 用途にシェルスクリプトを使うかっていうと、限定された趣味の世界で、趣味目的で書く、というところが現実的なんじゃないかなって思っています。また、「(高級言語を使わなくても)シェルスクリプトだっていろいろ出来るよ!」という気持ちもあるかもしれません。(PQI Air Card のようなめちゃくちゃ小さい Linux システムにもシェルは搭載されているので、CGI/sh で簡単なウィキシステムを書いて遊んでみたりしました。)

bash.CGI

CGI として動作させるために重要なのが、リクエストの解析です。必要なものは環境変数に詰まっていますし、POST送信の内容は標準入力を読めば自分で何とでも出来ますが、シンプルかつしっかり動くbash.CGIというコードのサンプルがあるので、それをモジュールとして使いたいと思います。このコードは、CGI/Perl における CGI.pm みたいなもので、GETによるURLに付随してくるパラメータやPOST送信されたデータをシェル変数に置き換えてくれるので、いろいろ捗ります。

cgi_get_POST_vars()cgi_decodevar()cgi_getvars() の3つの関数定義と、呼び出しの大元である cgi_getvars BOTH ALL コマンドを貼っつけたスクリプトファイルを bashcgi.sh として保存しておきます。

bootstrap

最近のナウいユーザインタフェイスをちゃっちゃか実現するために Twitter の bootstrap を使っています。今回はサーバーのルートに /css や /js といったディレクトリが展開されるよう配置しています。

shellchat

さていよいよ本題。シェルスクリプトによる CGI チャットのソースコードは次のようになりました。

#!/bin/bash

. bashcgi.sh

title='shellchat!'
logfile='./log.txt'
linenb='15'

if [ -n "$nick" -a -n "$msg" ]; then
  msg=$(echo "$msg" | sed 's/</\&lt;/g' | sed 's/\(http:\/\/[^  ]*\)/<a href=\1 target=_blank>\1<\/a>/g')
  nick=$(echo "$nick" | sed 's/</\&lt;/g')
  timestamp=$(date +"%m/%d %H:%M:%S")
  echo "<code>$nick</code> <span>$msg</span> - <span class=small>$timestamp</span><br />" >> "$logfile"
  cat<<EOF
Content-Type: text/html

<meta http-equiv="Refresh" content="0; URL=$SCRIPT_NAME?nick=$nick" />
EOF
else
  cat<<EOF
Content-Type: text/html
Pragma: no-cache
Cache-Control: no-cache

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <meta http-equiv="Refresh" content="40; URL=$SCRIPT_NAME?nick=$nick" />
    <link rel="stylesheet" href="/css/bootstrap.min.css">
    <script src="/js/bootstrap.min.js"></script>
    <title>$title</title>
  </head>
  <body>
    <div class="container-fluid">
      <div class="row">
        <div class="col-md-2"></div>
          <div class="col-md-8">
            <h1>$title</h1>
            <div class="well">
EOF

  [ -f "$logfile" ] && tail -n $linenb "$logfile"

  cat<<EOF
            </div>
          </div>
          <div class="col-md-2"></div>
        </div>
        <div class="row">
          <div class="col-md-2"></div>
          <form class="form-inline" action="$SCRIPT_NAME" method="post" enctype="application/x-www-form-urlencoded">
            <div class="col-md-8">
              <p class="text-center">
                <input class="form-control" type="text" name="nick" size="5" placeholder="Name" value="$nick" />
                <input class="form-control" type="text" name="msg"  size="59" placeholder="Input message here." />
                <button type="submit" class="btn btn-default">
                  <span class="glyphicon glyphicon-comment"></span>
                </button>
              </p>
            </div>
          </form>
          <div class="col-md-2"></div>
        </div>
        <div class="row">
          <div class="col-md-2"></div>
          <div class="col-md-8">
            <hr />
            <p class="text-right">
              shellchat by <a href="https://dyama.org/" target="_blank">dyama.org</a>
            </p>
          </div>
          <div class="col-md-2"></div>
        </div>
      </div>
    </div>
  </body>
</html>
EOF
fi

exit 0

全体的にどべえーっと長ったらしい HTML タグがありますが、ほとんどがデザイン部です。実際に処理しているのは数行しかありません。 冒頭で bashcgi.sh を読み込んで、シェル変数に POST 送信の内容を詰め込んでいます。変数 nick と msg があれば、ログに追記した後、ユーザにはページをリフレッシュするよう META タグを返しています。また、変数がない場合はそのままログを表示しています。

セキュリティ的にも性能としても、何もやっていない分、いろいろと問題があるのですが、一応ちゃんと動いています。

shellchat

実際に動かすと、上記のように表示されます。

艦これのSKK辞書を作ってみました。

なんだかもの凄く今更感があるのですが、角川ゲームスが提供するオンライン育成ゲーム「艦隊これくしょん」のSKK辞書を作ってみました。Githubにてホスティングしてますので、ダウンロードやFolkが自由にできます。 普段のタイピングでは使わないような旧日本海軍の艦船名(艦娘名)をはじめ、装備品やゲーム中に登場する敵キャラクターの名前などを492ワードを収録しています(現時点)。まだまだ用語を網羅しているとは言えませんので、どんどん充実していけたらと思います。

Kancolle words dictionary for SKK(Githubの公開ページ)

https://github.com/dyama/skk-dict-kancolle

収録語一覧

https://github.com/dyama/skk-dict-kancolle/blob/master/src/SKK-JISYO.kancolle

辞書はUTF-8ベースで記載されています。ご利用のシステムに合わせて変更してください。src ディレクトリ内の SKK-JISYO.kancolle が辞書ファイルですが、このファイルはメンテナンスのためにソートしていません。make を実行するとソート済みの辞書を生成します。適宜、使い易いように切ったり貼ったり変換して使っていただければと思います。 また、誤字脱字、追加した方が良さそうな単語、注釈を使った便利機能のアイディアなどがありましたら、コメントやIssueをいただけると幸いです。(もちろん、Forkしたものをプルリクされても結構です!)

OpenCASCADE6.7.0でレイトレーシングレンダリングを有効にする

OpenCASCADE 6.7.0 ではレイトレーシング方式のレンダリングをサポートしている事を前回紹介しました。今回は、実際にコーディングをして試してみたものを紹介します。

前提

レイトレーシングレンダリングが何ぞや、というのは、この記事を読んでいる方なら既にお分かりだと思いますので割愛します。OCCTにおけるレイトレーシングの設定は、AIS コンテキストでも Viewer でもなく、View に付随しています。レンダリング、つまり見た目の設定なので、当たり前と言えば当たり前ですね。これは逆に言うと、同じViewerにぶら下がっているいくつかの View は、それぞれ別のレンダリング方式を設定することができるという訳です。 また、レイトレーシングをサポートした事により、それまでの方式と区別するためにOCCTでは次のようにモードとして呼称しています。

  • Raytracing Mode レイトレーシング・モード
  • Rasterization Mode ラスタライズ・モード(従来からあるレンダリング方式)

レイトレーシングがサポートされたことによって、従来からあるラスタライズ・モードが使えなくなるわけではありません。バージョン6.7.0以前のコードも(見た目まわりに関しては)レイトレーシング・モードのサポートによって書き換えの必要はなく、そのままで従来方式のレンダリングでの表示が可能です。

使い方

では、実際にコードを見てみましょう。

void OCCViewer::initViewAppearance(bool is_raytracing, bool is_shadow, bool is_antialias, bool is_reflection)
{
    if (is_raytracing) { // Enable ray tracing mode
        view->SetRaytracingMode();
        view->EnableGLLight(Standard_True);
        is_shadow     ? view->EnableRaytracedShadows()      : view->DisableRaytracedShadows();
        is_antialias  ? view->EnableRaytracedAntialiasing() : view->DisableRaytracedAntialiasing();
        is_reflection ? view->EnableRaytracedReflections()  : view->DisableRaytracedReflections();
    }
    else { // OpenGL rasterize rennaring mode
        view->SetRasterizationMode();
    }
    // ...
}

これは私が開発しているナンチャッテCADビューアー「siren」のソースコードの一部です。レイトレーシングレンダリングを有効にするには、新たに用意されたメソッド呼び出すだけで済み、非常に簡単です。 解説しなくとも書いてあるとおりですが…一応ざっくりと紹介しておきます。

V3d_View::SetRaytracingMode() Viewをレイトレーシングモードに設定します。

V3d_View::SetRasterizationMode() Viewを従来(ラスタライズした形状をOpenGLに投げて描画する)方式に設定します。

V3d_View::EnableRaytracedShadows() / DisableRaytracedShadows() レイトレーシングによる影の表現(陰ではない)を有効・無効にします。

V3d_View::EnableRaytracedAntialiasing() / DisableRaytracedAntialiasing() レイトレーシングモードの時、アンチエイリアスをかけたレンダリングを有効・無効にします。

V3d_View::EnableRaytracedReflections() / DisableRaytracedReflections() レイトレーシングモードの時、形状の鏡面反射を有効・無効にします。反射率は AIS_Shape に関連付けされたマテリアル(材質)によって変化します。

これらのメソッドをViewの初期化時に呼んでやれば、レイトレーシングによるレンダリングを行います。すべてのオプションを有効にすると、次のように描写されます。  

occt670-raytracing-sample

球と面を配置して、材質設定を「金」にしただけですが、綺麗ですね!  

やっぱり重い

私の作業PC(NVIDIA NVS 3100M)ではお世辞でも快適とは言えないくらい動作が遅くなってしまいました。とは言うものの、リアルタイムでレイトレーシングレンダリングをしているわけですから、昔のPCに比べれば、対話的に視点を回転できるだけでもびっくりです。弟の作業PC(もっと良いグラボを積んでます)でレイトレーシングモードを有効にしたところ、少ない形状数であれば、ほぼリアルタイムでぐりぐり動いているようです。 思いっきりハードウェアパワーに依存しているところですので、レイトレーシングモードの濫用は避けるべきだと思います。MayaやMAX、Blenderといった3D CGアニメーションソフトも、作業画面とレイトレーシングが有効にできるレンダリング画面は別になっていますし、用途に合わせて使っていければいいと思います。 レイトレーシングモードに絡んで、新しく追加されたGLGSベースのシェーダーとライトについては、次の記事で紹介したいと思います。

JavaScriptによる二進数時計

以前書いたコードが出てきたので貼っておきます。今見直してみると、ちょっとムダがあるコードですね。 JavaScriptは書けません、でお茶を濁しておきましょう。

// 2010/01/08 jbClock by dyama
// for Firefox, Opera and Google Chrome

var BgColor = '#F00000';
var BaseColor = '#351309';
var ActiveColor = '#FF470F';
var Height = 8;
var Width = 16;

// 文字列を指定した桁数kになるまで頭にmを挿入する
function kt( s, k, m ){ while( s.length < k ){ s = m + s;} return s;}

function bclock()
{
    var n = new Date();
    // toString(2) ... 二進数文字列にする
    // kt で頭に文字列"0"を挿入して返す
    // 0と1の文字列だと、後でHTMLを一括置換した時に置換対象以外も
    // 置換してしまうので一時的に文字0を文字列$zに、文字1を文字列$oにする
    var h = kt(n.getHours().toString(2),5,0).replace(/0/g,'$z').replace(/1/g,'$o');
    var m = kt(n.getMinutes().toString(2),6,0).replace(/0/g,'$z').replace(/1/g,'$o');
    var s = kt(n.getSeconds().toString(2),6,0).replace(/0/g,'$z').replace(/1/g,'$o');
    // 0だった場合と1だった場合のHTMLタグを準備
    var t = '<td bgcolor="' + ActiveColor + '" height="' + Height + '" width="' + Width + '"></td>';
    var f = '<td bgcolor="' + BaseColor + '" height="' + Height + '" width="' + Width + '"></td>';
    var o = document.getElementById("area");
    // "$z$z$o$z$o" のような文字列のままタグ挿入
    var v = '<tr><td bgcolor="$a" height="' + Height + '" width="' + Width + '"></td>' + h + "</tr><tr>" + m + "</tr><tr>" + s + "</tr>";
    var a = (n.getSeconds()%2)?BgColor:BaseColor;
    // 最後に$zを0用のHTMLに、$oを1用のタグにHTML全体を一括置換
    o.innerHTML = v.replace(/\$z/g,f).replace(/\$o/g,t).replace(/\$a/,a);
    // 1秒ごとに実行する
    setTimeout("bclock()", 1000);
}

これを実行すると、次のように見えます。

OpenCASCADE 6.7.0 のアナウンス

OpenCASCADEの最新バージョン6.7.0が開発者サイトでアナウンスされています。
記事によると、6.7.0では特に visualization が強化されたようで、簡単かつ高速に高品位のレイトレーシング・レンダリングがビューで可能になったとのことです。

現行リリースの最新版である6.6.0までは、正直に言うと、お世辞でも「綺麗な見た目」は提供されていませんでした。OCCT自体、三次元幾何演算部分が中核となっているライブラリですので画面表現については後まわしになっていたのかもしれません。

結果的にCATIARhinocerosといった商用CADに、第一印象(見た目)で劣るように思われがちになっている感触がありましたが、今回の6.7.0では、商用CADにも負けない美しいビューを表現できるようになったようです。

OpenCASCADE 6.7.0 の新機能

レイトレーシングによるフォンシェーディング・鏡面反射のサンプル
レイトレーシングによるフォンシェーディング・鏡面反射のサンプル
光源と陰を正確に演算しているため、小さな溝やエッジまでよりリアルかつ自然に表現が出来ている。 光源と陰を正確に演算しているため、小さな溝やエッジまでよりリアルかつ自然に表現が出来ている。
半透明処理では、重なり合う物体同士がうまく表現できている。 半透明処理では、重なり合う物体同士がうまく表現できている。
金属表現もこのとおり。 金属表現もこのとおり。

記事をかいつまんで要約しますと、

  • phong シェーディングに対応

三角形ピクセルベースの法線補完と高度な照明モデルを使用して、高品質なシェーディングができるようになったらしいです。これまでは、近似などでごまかしながらシェーディングを行なっていたみたいですが、今回はしっかりとポイントライト(点光源)とディレクショナルライト(平行光源)を使って陰が出来るようになったことで、見た目が大幅に向上したとのことです。

  • 鏡面反射と環境マッピングの対応

レンダリング画面の品質を大きく左右する鏡面反射環境マッピングもサポートされたようです。レイトレーシングがまともに実装されて初めて実現できる機能です。完全な鏡を表現しなくとも、プラスチックや塗装された金属にうっすらと映り込む周りの風景は、より直感的に利用者にイメージを伝えることができるようになると思います。

  • アンチエイリアス処理の改善

6.6.0までは、アンチエイリアス処理を有効にすると、アンチエイリアスであるにも関わらずジャギー(物体の境界のギザギザ)が目立つようになっていました。全然美しくない上に、無駄な処理をするわけで全く使っていませんでしたが、今回の改善でまともに使えるようになった模様です。

  • 半透明オブジェクトの表現の改善

これまでは、半透明オブジェクトを重ね合わせると物体の順序がめちゃくちゃに表現されていました。これは、まともにレイトレーシングをしていなかったため、視点から、手前から順に並んでいるはずの物体の位置を上手く表現できていない事が原因です。今回、これも改善されたようで、CADでなくてはならないこの表現も上手く行きそうです。

  • OpenCLでの処理

レイトレーシングを実装するにあたり、画面の描画コストはこれまで以上に大きくなることは明白です。そのため、並列処理を行うOpenCLをサポートして描画速度の改善を図っています。

レイトレーシングを有効にするコーディング

レイトレーシングモードでの描画を有効にするには、従来のコードをほとんど書き換えることなく、簡単にできるようです。
記事では、V3d_View::SetRaytrasingMode() を実行するだけで有効にできると書いてあります。また、レイトレーシング実装に伴なって DRAW コマンドも追加されており、利用方法もソースコードレベルで示されているみたいです。

今のところの制約事項

6.7.0では、レイトレーシングに関する次のいくつかの機能がまだ制限されているとのことですが、次回以降のリリースで順次利用できるようになっていくそうです。

  • テクスチャーマッピングは今のところ未サポート、従来のテクスチャもレイトレーシングには移植されていない。
  • レイトレーシングが使えるのはポリゴン形状のみで、点や曲線はサポートされていません。(つまり、ワイヤフレームなどもレイトレーシングが使えません)ここで言うポリゴン形状とは、平面分割されたポリゴンメッシュではなく、OpenGL 描画時における面、すなわち自由曲面も含まれているものだと思います。
  • 三角形メッシュの一致問題(OpenGLと同様)。描画時におけるポリゴンメッシュ分割による幾何誤差の事だろうと思います。分割精度を上げれば実用範囲において回避できるだろうとの注釈も。
  • CPU(つまり、ソフトウェアレンダリング)とIntelのGPU(Intel HD Graphicsなど)でテストされていません。
  • また、MacOS Xでもテストされてません。ユーザがこれらの環境に関するパッチ(やレポート)を提供することを求めています。
  • レイトレーシングさせる形状は、今のところOpenGLのVBOを利用せずメインメモリ上から生成するため、メモリ使用量が多くなってます。
    ** 2倍から3倍以上のメモリ使用量になってます。2GBのVRAMで、3,000,000ポリゴン程度。

これらの事は次期リリースに期待しつつも、現状だけでも充分に表現力がアップすると思われます。

DirectXのサポート!?

また、本記事とは別にOCCTのDirectXサポートについての議論も記事になっていました。
曰く、

  • OpenGL に加えて Direct3D レンダラを搭載するのは面白そう。
  • ただ、DirectX を大規模な開発をしてサポートするなら、それなりのメリットが必要。
  • Direct3D レンダラは特定のプラットフォームでしか動かない。
  • レンダラが二つになるということは、バグも倍増されてメンテが大変になる。

とのことでした。ここでは、OCCT本体に実装するのではなく、サードパーティ製の visualization ライブラリとして開発ターゲットにするのは良い方法とも述べています。
個人的には、DirectX の需要はまるでないのですが、90年代後半から今まで培われてきた技術があることは否定しません。終焉を迎えつつある技術でも選択肢が多くなることは良いことだと思います。