BRDFシェーダ

最終更新:2016/09/06

BRDFは、Bidirectional Reflectance Distribution Functionの略で、日本語では双方向反射分布関数という。数学的なことはあまりよくわからないんだけど、LightWaveにおけるBRDFシェーダは簡単に言ってしまうと、特定の光源に対して反射する面のハイライトに変更を加えることができるもの。異方性反射に似たようなこともできる。

異方性反射に関する記事ではAnisotropicノードやAni-Reflectionsノードを使ってSpecular ShadingとReflection Shadingを実現し、Diffuse Shadingを使って金属表面のヘアライン加工の質感の再現を試みた。しかし、サーフェースや光源の色にレンダリング結果が影響を受けなくなるなどの制約もあることも書いた。BRDFシェーダは、厳密な意味での異方性反射を再現することはできないけど、ハイライトに色を着けることが可能で、光源に特殊な設定をすることなく比較的手軽な設定でハイライトの形状等を制御できる。

まず、次の画像のような球状のオブジェクトを用意する。もっとも単純な白色のスポットライトをひとつ配置しただけの簡単なシーンで、ハイライトは円形になる。これにBRDFシェーダを適用していく。

BRDF000

Regularモード

最初に、「Regular」モード。ハイライトの色(Color)、反射光(Specular)、光沢(Glossiness)を指定できるのみで、ハイライトの形状は通常と同様になる。

BRDF001

上の画像の設定でレンダリングすると次の画像のようになる。光源の色とは無関係に、ハイライトに黄色が適用され、光沢を弱めに設定したためぼんやりとした輪郭になる。ハイライトの位置が同じというところが重要で、BRDFシェーダは特定点における光の反射のみに適用されるものであることがわかる。

BRDF002

Anisotropicモード

次に、「Anisotropic」モード。ハイライトの色、反射光、光沢に加えて、「Anisotropy」と「Direction」を角度で指定できる。Anisotropyは異方性反射のことだけど、できることはかなり限定的で、放射状の異方性反射はある程度模擬できるものの、同心円状の異方性反射を模擬することまではできない。「Anisotropy」と「Direction」を設定するとハイライトの形状をずらすように互い違いに歪ませることができ、「Anisotropy」を「90°」、「Direction」を「0°」に設定するとハイライトの中心点で交差する扇状の反射になる。

BRDF003

上の画像の設定でレンダリングすると次の画像のようになる。ハイライトが緑色になり、異方性反射風の扇状の反射になっていることがわかる。「Anisotropic」モードでもハイライトの中心点は同じで、光を当てる方向やカメラの視点を変えなくてもBRDFシェーダの効果を得られる場所には変化がないことがわかる。

BRDF004

AnisotropicⅡモード

最後に、「AnisotropicⅡ」モード。「Anisotropic」モードの設定項目に加えて「Mapping」を指定できる。マッピングに「Cylindrical」を指定し、X、YまたはZのいずれかの軸を指定するとオブジェクトの軸に沿ったハイライトを生じる。「Anisotropy」と「Direction」の挙動は「Anisotropic」モードとは異なり、「Anisotropy」と「Direction」の両方を「90°」に設定するとハイライトの中心点で交差する扇状の反射になる。

BRDF005

上の画像の設定でレンダリングすると次の画像のようになる。ハイライトが赤色になり、異方性反射風の扇状になっているのは「Anisotropic」モードと同様だけど、ハイライトの中心点がオブジェクトのY軸に移動している。3つのモードのうち、動作としてはもっともAnisotropicノードに近いけど、同心円状の異方性反射の模擬が難しい(少なくとも、試した範囲では実現できなかった)上に、Anisotropicノードと異なり、異方性反射の中心点を任意の位置に移動させられないため制御が難しい。UVマップを指定することもできるけど、更に高度な設定になるので、そこまでする必要があるかどうかは判断の分かれるところ。

BRDF006

ティーポットで実験

それぞれのモード単体でできることはそれほど大したことはないけど、ひとつのBRDFシェーダに3つまでのレイヤーを設定できるので、自動車の塗装のように何層かの塗装面におけるハイライトを制御したい時に有効。

例えば、何の変哲もないティーポットのモデルを配置したシーン(左の画像)にBRDFシェーダの「Anisotropic」モードを二層にわたって適用することで、ハイライトにヒステリシス曲線のような歪みを生じさせ、表情を持たせることができる(右の画像)。

BRDF008

BRDFシェーダはその特性上、平面よりはハイライトが出やすい曲面のほうが効果がはっきりとわかるけど、光源の方向やモデルの角度などによって立体感が薄いと感じられる場合などに光源に依存しない反射を生じさせることで立体感を増すこともできる。

作品への応用

実験だけでは効果がわかりにくいと思うので、更に進めて実際の作品に反映したらどうなるか試してみた。次の画像はBRDFシェーダ適用前のもの。左右の白い斜線の入った青い部品は機首を中心にして山なりに角度がついているんだけど、光源の都合などで立体感がわかりにくい。

BRDF009

次の画像はBRDFシェーダ適用後。白色と青色のサーフェースに全体的に水色のハイライトを入れた。機首や主翼前縁部のような曲面のほうがシェーダの効果がはっきり見えるけど、平面にもレイトレースではわかりにくかった部分にハイライトが出て立体感はやや増した。ただ、本来の光源方向がわかりにくくなって嘘っぽく見えてしまうという欠点もあるので、度を超さない程度に使うのが良いように思う。

BRDF010

バグについて

最後に、BRDFシェーダにはLightWave3D 10.1の時点でバグがあり、サーフェースにBRDFシェーダを適用したままモデラーでオブジェクトのファイル間、レイヤー間のコピー&ペーストを行うとクラッシュする。モデラーではシェーダの効果を確認できないのでレイアウトで最後の仕上げに適用するようにしたほうがいい。この問題は、機能を一時的にオフにするだけでは解決できないため、シェーダ適用後にモデルを修正する必要が発生したら、シェーダをサーフェースから完全に除去する必要がある。その際に、パラメータが多いので設定を忘れてしまわないようにどこかにメモしておかなければならない。そういった意味では使い勝手が良くないシェーダではある。

関連記事

異方性反射(Anisotropicノード)

最終更新:2016/09/06

異方性(アニソトロピー、Anisotropy)というのは、物質の物理的性質が何かの方向により変わる特質のこと。宝石をはじめとする鉱物に光が入射する角度によって色が変わって見えたり、偏光性のある結晶のように角度によって光の透過率や屈折率が変わることなんかをひとまとめにして異方性という。異方性反射もそのひとつ。金属の表面に何らかの加工が施されていると、ピカピカに磨いたものとは異なる光の反射の仕方を見せることがある。

身近なところでは、CDやDVDの裏面なんかがそれにあたる。音楽や映像のデータを刻むために薄いアルミニウムの板に目に見えないほどの細かい同心円状の加工がしてあることで、光の当たり方によって虹色に光って見える。新旧を問わず、光ディスクは同様の特徴を持っている。

また、アルミニウムやステンレスなどの金属製品の表面を一定方向にわざと荒らして独特の風合いを出すヘアライン加工(ヘアライン仕上げ)が有名。同心円状にヘアライン加工をすると円の中心で交わる扇状の異方性反射を生じ、放射状に加工を施すと同心円状の異方性反射を生じる。加工と反射がちょうど直交するのが特徴。特に、ヘアライン加工による異方性反射というと同心円状の加工をイメージする人も多いはず。

一応、どんな3DCGソフトウェアでも、オブジェクトの表面に加工がされているように凹凸をつけてやれば異方性反射と似たようなことはできる。ただ、ヘアライン加工くらいの微細なレベルになるとポリゴンの数が膨大になるうえ、手間もレンダリング時間もかかるので、おのずと限界がある。そこで、LightWaveでは異方性反射を模擬するAnisotropicノードというものが備えられているのでそれを利用する。この記事を書いている時点で利用しているLightWaveのバージョンは10.1。

サーフェースの設定関連ではノードの編集はあまり得意ではないんだけど、勉強もかねて同心円状のヘアライン加工を施した金属表現に挑戦してみた。次の画像がレンダリングしたもの。

Anisotropy007

色々試行錯誤してみた結果、ノードの構成は次の画像のような感じになった。

Anisotropy000

この画像だけだと設定がわからないと思うので、順に説明していく。まず、Anisotropic (1) ノード。

「Anisotropy U」と「Anisotropy V」がもっとも大事なところで、VをUよりも十分小さい値にすると、放射状の異方性反射になる。つまり、ヘアライン加工は同心円状ということ。逆に、VがUよりも大きいと同心円状の異方性反射になる。次に大事なのは「Specularity」だけど、ここでは「100%」にしている。「Mapping」を「Cylindrical(円柱状)」にしておかないと同心円状のヘアライン加工にならないので注意。

Anisotropy001

次にAnisotropic (2) ノード。Anisotropic (1) よりも「Specularity」を若干控えめの「70%」にして、Vの値を少し大きめにする。Anisotropic (1) ノードとAnisotropic (2) ノードの「Color」出力をMathグループにあるScalarのAddノードで足してやってSurfaceの「Specular Shading」に接続する。

Anisotropy002

Anisotropic (1) ノードとAnisotropic (2) ノードのColorは白(RGB = (255,255,255))になっているけど、実はなんでもいい。「Specular Shading」に接続した時点で色の情報は無視される。光源の色を変えても異方性反射の色が変わることはない。どうしても異方性反射に色を着けたければ、Surfaceの「Color」に直接接続することになるんだけど、実物感はかなり薄れる。

次に、異方性反射と同じ理屈で鏡面反射を模擬するAni-Reflectionsノードを設定する。ここでも重要なのは「Anisotropy U」と「Anisotropy V」で、U > V にすることで放射状の鏡面反射を生じさせることができる。また、通常の鏡面反射の設定と同様に「Dispersion」を設定することで反射をぼかすこともできるし、球状反射マップを指定することもできる。ノードの設定が優先されるので、サーフェースの環境タブで鏡面反射マップを指定していても無視される。

Anisotropy005

Ani-Reflectionsノードの「Color」出力をSurfaceの「Reflection Shading」に接続する。これだけでも異方性反射らしい感じにはなるのだけれど、肝心のヘアライン加工が見えない。

そこで、LightWave付属のコンテント・ディスクに入っている画像を利用する。画像は Content\Images\Surface\Anisotropic フォルダにある brushed_03.bmp を指定する。なお、この画像はLightWaveを購入した人にのみ使用権が与えられる契約になっているものなので、フリー素材ではなく、ここでは配布できない。

Image (1) ノードは次の画像のような設定になっている。「Mapping」に「Spherical(球状)」を指定しておかないと円柱の上面に同心円状のヘアラインが出ないので注意。

Anisotropy003

Image (1) ノードの「Color」出力をAnisotropic (1) ノードとAnisotropic (2) ノードの「Color」入力に接続することで、異方性反射にヘアライン加工のような同心円状の筋が入るようになる。しかし、異方性反射以外の部分にはヘアラインが見えないのでさらにひと工夫。

Adobe Photoshopで先ほどの brushed_03.bmp を加工してノーマルマップ用の法線マップを用意する。ノーマルマップはメニューバーから「フィルター」-「3D」-「法線マップ」を選択すると設定ウィンドウが表示されて生成できる。あまり大きな凹凸をつけるつもりはないので、「ディテールスケール」を「10%」、「ぼかし」を「0」に設定して生成する。「コントラストのディテール」は特に変更しなかったが、「弱」「中」「強」ともに「20%」。

Anisotropy008

法線マップの機能はPhotoshop CC 2015で追加されたものだそうなので、古いバージョンには実装されていない。法線マップを自力で描くのはほぼ不可能と言ってもいいくらいなので、Photoshopを持っていない場合などは、ネットで画像をアップロードするとノーマルマップを生成してくれるウェブサイトがあるので、そちらを利用してもいいかもしれない。

保存した法線マップをNormalMapノードに読み込む。「Mapping」や軸などは Image (1) ノードと同様の設定にしておく。「Amplitude」はごく小さく、「5%」にしておく。今回は微細な加工を意図しているため、あまり大きくしてしまうと表面にモアレのようなノイズを生じやすくなる。バンプ・マッピングでも似たようなことはできるけど、ノイズを生じやすく、ヘアライン加工のような場面ではあまり使い勝手が良くなかった。

Anisotropy006

NormalMap (1) ノードの「Normal」出力をサーフェースの「Normal」入力に接続する。これで微細な凹凸が表面に追加され、異方性反射にも若干の分散のようなものが生じてそれらしくなる。

ただ、光が当たっていない部分のヘアラインがまったく見えないので、Diffuse Shadingを使用する。Diffuse(拡散レベル)用のテクスチャを同じく brushed_03.bmp からPhotoshopで加工する。レベル補正をかけて、明るいところはそのまま、暗いところを更に暗くするように設定。(他のMathノードなどを使って補正することができるのかもしれないけど、思いつかなかったのでPhotoshopで無精した)

Anisotropy009

保存したDiffuse用のテクスチャをImage (2) ノードに読み込む。これでも明るすぎたようなので、「Luma」出力をMathグループのDivideノードで10分の1に輝度を縮小させてSurfaceの「Diffuse Shading」に接続する。ちなみに、LumaはLuminanceの略語というか、コンピュータ用語における造語だそうで、輝度を表す。「Luma」出力の代わりに「Color」出力を使っても結果は同じ。

Anisotropy004

Diffuse Shadingを使用することによって、同じ表面の中でも明るいところと暗いところができ、同心円状のヘアライン加工らしい筋が見えるようになる。

ただ、これにはひとつ問題がある。勉強不足で理屈はよくわからないんだけど、Diffuse Shadingを使用するとサーフェースの色の情報がまったく受け付けられなくなる。Make ColorノードやColor Toolノードを追加してSurfaceの「Color」に接続しても同様。

塗装もしていない金属の地金ように色のないオブジェクトの場合はこれでもいいんだけど、塗装された表面を表現しようとするとヘアラインを諦めるか、クリアコーティングのように半透明のサーフェースで覆うといった別の工夫が必要になる。鏡面反射を設定している場合、背景色を変更すればその色を映し出させることはできるけど、他のオブジェクトにも影響を与えてしまうので根本的な解決にはならない。光源の色に影響を受けないのはSpecular ShadingやReflection Shadingと同様で、Shading系の機能を使用すればするほど実物感は増すものの、サーフェースの表現には制約を受けるようになる。

以上のように、ノードの設定は結構大変。大変ではあるんだけど、ノーマルマップのようにノードを使わないと実現できない表現もあるのですべてを避けて通るのも難しい。

最初は、順を追って各ノードの効果をレンダリング画像とともに例示していこうと思っていたんだけど、とてもではないけどひとつの記事としては長くなりすぎてしまうので、最終結果の説明のみに留めた。

関連記事

アンチエイリアス部分にアルファチャンネルを適用する

最終更新:2016/09/06

3DCGモデルのエッジ・ラインの抽出について書いた2013年5月14日の記事では、エッジ・ラインだけを残してそれ以外を透明にするためにGIMPの「色域を選択」機能で一括選択してざっくり削除していたけど、アンチエイリアシングで生じた暗い色のピクセルもそのまま残ってしまい、あまり綺麗にはできていなかった。

そこで、8ビット256階調のアルファ・チャンネルを利用してピクセルが暗くなるほど透明度が増すように設定し、背景に溶け込ませることができないだろうかと考えた。画像処理を得意とするソフトウェアを開発する企業の中には当然同様のことを考える人はいて、誰もが知っているAdobe Photoshopはもちろん、フリーライセンスのGIMPでも「レイヤーマスク」という機能で実現されている。モノクロ256階調のレイヤーマスクが黒に近いほどレイヤーの表示は透明に近づき、白に近いほど不透明度が増していく。

マスクを使うとなれば、グレースケールとしても使える画像のほうが何かと都合がいいので、前の記事では、背景色やサーフェース色を暗い青 RGB=(0,0,32) に指定していたけど、これを黒 RGB=(0,0,0) に設定しなおす。エッジ・ラインの色は白 RGB=(255,255,255) で同じ。前回はLightWaveの出力をアルファ・チャンネルとともに32ビットPNG形式で保存していたけど、あえてアルファ・チャンネル情報を破棄して24ビットPNG形式で保存する。

今回用意したのは次の画像(モデルは前回のものとは若干異なる)。

Alpha005

Adobe Photoshopによる方法(Photoshop CC 2015)

Photoshopで対象となる画像を開き、レイヤーパネルの下に並んでいるアイコンの中の左から3つめの「レイヤーマスクを追加」ボタンをクリックする。メニューからでは、「レイヤー」-「レイヤーマスク」-「すべての領域を表示」を順に選択する。すると真っ白なレイヤーマスクのサムネイルが当該レイヤーの隣に追加される。

Alpha000

次に、対象画像のレイヤー(カンバス)を全選択(Ctrl+A)し、コピー(Ctrl+C)しておく。レイヤーマスクのサムネイルをクリックして選択状態にして、更にAltキーを押しながらクリックすると、レイヤーマスクの編集画面になる(この辺はちょっとわかりにくかった)。コピーしておいたレイヤーをペースト(Ctrl+V)する。選択状態になっていてペーストできない場合は、いったんカンバスの外をクリックするなどして選択を解除しておく。

LightWaveでの画像保存でアルファ・チャンネルを破棄したのは、コピーしたレイヤーの余白に透明部分があると普通にペーストするだけでは同じ位置に貼り付けられないことがあるのと、透明だった部分のマスクは真っ白のままで変わらないので、あらかじめ黒で塗りつぶしておかなければならないから。位置については「編集」メニューから「特殊ペースト」、「同じ位置にペースト(Shift+Ctrl+V)」を順に選べばいいんだけど、1ピクセルでもズレると結果が大幅に変わってしまうので、余計な手間はないに越したことはない。

なお、今回は白い実線部分を残しておきたいので、「階調の反転」は行わない。

Alpha003

再びレイヤーのサムネイルをクリックすると、元は黒かった部分が透明になっている。わかりにくければ、背面に何か色のついたレイヤーを一時的に差し入れてみる。エッジ・ラインに隣接するアンチエイリアスのピクセルもレイヤーマスクの階調に従って半透明状になっているので、これを「ファイル」メニューから「別名で保存」を選択してPNG形式で保存する。

GIMPによる方法

GIMPの場合はPhotoshopよりもシンプル。レイヤーなどが表示されているパネルで対象画像のレイヤーを右クリックすると、「レイヤーマスクの追加」というメニューがある。メニューからでも「レイヤー」-「レイヤーマスク」-「レイヤーマスクの追加」で実行できるけど、右クリックのほうが操作は直感的。

Alpha001

クリックすると、どのようにレイヤーマスクを生成するのか「レイヤーマスク追加」ウィンドウで聞いてくるので、「レイヤーのグレースケールのコピー」を選択して「追加」ボタンをクリックする。これだけでいい。GIMPのインターフェースに慣れてさえいれば、レイヤーマスクの編集の手間がない分、Photoshopよりも手軽ではある。

Alpha002

対象画像を「可視部分」と「不可視部分」に分けて重ねているだけで、特殊なアルゴリズムを用いているわけではないのでソフトウェア間の性能差は生じにくく、Photoshopでやっても、GIMPでやっても基本的に結果は変わらない(はず)。

レイヤーマスクを利用して加工したものが次の画像。白い実線以外の部分は透明になっているのがわかりやすいように、ウェブサイトの背景画像の上に表示されているもののスクリーンショットをとった。元の画像よりもエッジが細くなった印象はあるけど、従前の方法よりシャープさが増し、不自然な段差も少ない。エッジの太さについてはLightWave側でなんとでもできる。全体的には綺麗にできていると思うけどいかがだろうか。

Alpha004

関連記事

参考記事

MediaWikiをアップグレードしたら画像が表示されなくなった問題

最終更新:2016/09/06

今までMediaWiki 1.24を使っていたんだけど、ふと何気なく自分のウィキを見てみたら、ウィキメディア・コモンズから呼び出している画像が表示されなくなっていた。MediaWikiの公式サイトを調べてみたら、InstantCommonsという機能に変更があって、HTTPS接続じゃないとコモンズから画像を引っ張ってこれなくなったそうだ。比較的最近のバージョンじゃないとダメみたいなので、最初は何の気なしに気軽にアップグレードを始めてみた。

この記事を書いている時点の最新版はMediaWiki 1.26.2だったので、いつものようにアップグレードをしてみたんだけど、今度はコモンズの画像だけじゃなくて、ローカルに保存されているはずの画像も呼び出せなくなってしまった。画像をクリックして直接表示させようとしても、Internal Server Errorが出てしまって表示できない。

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, support@sakura.ad.jp and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.

慌ててしまった私は、1.24に戻すことを考えたんだけど、これがまた非常に面倒で、MediaWikiのソフトウェアはともかく、データベースを復元できない。最新版ではデータベース内のテーブルから削除されてしまったフィールドもあったりして、さくらのレンタルサーバーの管理ツール(phpMyAdmin)を使ってもバックアップ・ファイルからインポートされている気配もない。

そもそもXML形式でバックアップしていたのがいけなかった。XML形式でのデータベースの復元は最新のMySQL 5.6でようやく実装されたものらしく、MySQL 5.5を指定している私のデータベースではそもそも無理という結論になった。一晩かかってもデータベースを復元できなかったので、その方向は諦めた。

そこで、ひとまず1.26にアップグレードはして、画像が出ない状態に戻した。そのうえで調べてみると、どうもMediaWikiのバグ・フィクスの影響で、MediaWikiの画像を保存しておく/imagesディレクトリの.htaccessに問題があるらしいことがわかった。さくらのレンタルサーバー非公式FAQによると、Optionsが使えない設定になっているそうだ。

MediaWiki 1.26.2 の .htaccess

# Protect against bug 28235
<IfModule rewrite_module>
	RewriteEngine On
	RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]
	RewriteRule . - [forbidden]
	# Fix for bug T64289
	Options +FollowSymLinks
</IfModule>

MediaWiki 1.24.2 の .htaccess

# Protect against bug 28235
<IfModule rewrite_module>
	RewriteEngine On
	RewriteCond %{QUERY_STRING} \.[^\\/:*?\x22<>|%]+(#|\?|$) [nocase]
	RewriteRule . - [forbidden]
</IfModule>

Options +FollowSymLinksという部分を#でコメントアウトして、/imagesディレクトリに保存する。

自分のウィキをリフレッシュしてリロード(Ctrl+F5)してみたら、無事に画像が表示された。ウィキメディア・コモンズの画像も表示されるようになっていた。おそらく、内部的にはローカルの画像を探す振りをしながらウィキメディア・コモンズにアクセスしにいっていて、ローカルの設定に影響を受けてしまってるのではないかと推測。

これ以降、アップグレードする度に同じ問題が起こることが考えられるので、備忘録を残しておくことにした。とにかく、MediaWikiをアップグレードして何か問題が起こっても、ダウングレードは最終手段と考え、慌てず騒がず同じ問題に行き当たった人が書いた記事がないか探してみるべきだと痛感した。

関連記事

参考記事

イラストがんばってるのに評価されていないと思う方へ

最終更新:2017/01/16

「私は自分なりに必死に頑張って絵を描いているのに作品がなかなか評価されない」と思い悩んでいる方は多いと思います。

 絵を鑑賞するのにそれほど時間は使いません。歴史的な名画だとしても、かなりじっくり鑑賞して数分くらいでしょうか。対して小説は最後まで読んでみないことには面白いかどうかわかりません(速読法ができる人とか特殊技能がある人は除きますよ)。
 言語に影響を受けず、短時間で鑑賞できるのが絵の長所でもありますが、描く側にしてみれば制作には相当な時間を要します。故に、というか当然の流れとして自分の絵は自分を表現したものと考える人も少なくありません。仮に1時間で描いた絵だとしても、30秒しか鑑賞してもらえなかったら観る側と描く側の時間感覚は120倍も差があることになります。実感として時間感覚の落差を知っているかどうかには天と地ほども差があるのは皆さん自身がよく知っていることでしょう。

 それに加えて、作者の自己表現である他に娯楽や商材の一部(あるいは全部)としても捉えられるものである以上、「上手・下手」「好き・嫌い」「使える・使えない」「売れる・売れない」などまるでコンピュータの「0」か「1」かみたいな二極的な評価しか出ません。制作に要した時間的資源や労力はまったく考慮されず、「中間はないのか」と、それに歯がゆさを感じるのはとてもよくわかるのです。
 入試や資格試験じゃあるまいし、そこに至るまでの経過の如何に関わらず「不合格」みたいな残酷な結果を出され続けるほうの気持ちにもなってみてくれ、と思うのも無理はないことです。
 それに対して既に人気が確定した絵描きさんの作品は何を描いても、それこそラクガキの類でも「合格」とでも言わんがばかりに自分の全力よりも高く評価されるのを理不尽に感じることもあるでしょう。
 書店で売っている「描き方」本や、イラスト投稿系SNSによくあるメイキングや講座を読んでその通りにしてみても必ずしも上手くなるとは限らなくて、「私と一体何が違うというのだ?」という誰も答えてくれない疑問の迷路に迷い込んでしまうのもよくわかるのです。

 ところが、「私はがんばったよ!」と主張してみても「出力された結果、すなわち絵がすべてなんだから、その中から努力を汲み取ってそれを含めて評価しろと言われても無理」という『もっとも論』を言われてしまって余計にヘコむということも珍しいことではないと思われます。

 社会の右も左もわからない新人でも即戦力を求められるお寒い時代を作り出してしまったのはダメな大人である私にも責任の一端はあるとは思いますが、苦し紛れながら十数年にわたる時間経過の中で徐々に形成されてしまった時流を個人の力で変えようとするのも風車に突撃するドン・キホーテのごとくです。

「苦しくても絵を描き続けて上手くなれば自然と評価されるようになるよ」と慰められることもあるでしょう。でも、「私の今の気持ちは?」、「近い将来、上手くなる前に心が折れて絵を描くのをやめてしまったら?」と考えてしまうのが人間というものです。何事にも動機は必要なもので、評価されていない現在から続く曖昧模糊とした未来を信じて行動し続けるというのは実に大変なことです。

 じゃぁ、漠然とした未来への不安と戦いながらがんばっている自分を誰が認めてくれるのかという話になりますよね。
 他でもない、「自分のがんばりは自分が認めるしかない」のです。

 前書きが長くなりましたが、ここからが本題です。

 ただし、これにはひとつ条件があります。

 それは、

「がんばっていない自分も認める」

 ということです。

 私の本業は技師なので絵描きさんの感覚とは違うかもしれませんが、昨日まで世の中になかったものを造り出すという意味ではクリエイターと言えなくもないので、本業の絵描きさん(特に個人事業でやっているフリーイラストレーターの方)とはまた別の考え方として読んでもらえればと思います。

 結論から先に言ってしまうと、「絵を描いてるとき」というごく短時間だけを「がんばった」と思ってしまうとその時点で自分の目を通した自分の成果の評価がフラット(わかりにくければ「冷静な気持ち」とでも言ったほうがいいでしょうか)ではなくなってしまうので、あまり適切じゃないと思うのです。

 結局のところ私は会社員なので、土日祝日以外は毎日会社に行って、決められた時間働いて帰るという生活なわけです。がんばってる日もあれば、やる気が出なくてサボってる日もあるし、仕事とは直接関係ない書類の始末に追われてる日もあるし、体調が悪くて休んでる日もあるわけです。で、最終的に半年に一回自分に対する評価が下されるわけです。評価対象となる期間の尺が長いので、下された評価を割とフラットな気持ちで聞くことができるのです。がんばった日だけで評価されるわけではないからです。(もちろん、職務上の義務を果たしていることが前提ですよ。)
 そういうのに慣れているせいもあるのでしょうけど、たまにpixivなどに作品をアップすると、がんばった日、サボってた日、面倒な作業をイヤイヤやってた日、所用があって作業できなかった日、体調が悪くて寝てた日などいろいろあったな、と思うとアップ後に出てきた評価に過剰な期待を持たずに「そんなところか」とフラットな気持ちで受け止められるのです。
 上を見ればキリがないので上は見ません。もともと底辺にいるのでわざわざ下も見ません。それが自分の作品に対する絶対評価なのだとただ純粋に捉えます。

 ところで先日、あるところで「宝石ってどうやって描くの?」という話になったので、力試しのつもりで宝石の3DCGを作りました。ネットから資料を探すところから始めて制作時間は4時間くらいでした。もののついでだからpixivにアップしておいたら一晩で150点になっていて「え?」と思ったものです。150点くらいで何を喜んでるんだよ、と笑われそうですが、何ヶ月もかけて制作して一年間も置いていても100点にもならない絵がたくさんあるのに、と考えれば私にとっては事件だと思いませんか。
 制作時間は4時間でも、その前に自分でいろいろ研究したこと、本を買って勉強したこと、ソフトウェアの能力を試す実験をしてみたこと、うまくいかなくて挫折したこと、自分なりに考えたことなどすべてを投入した4時間だったのだから、それらを含めての一晩で150点なのだろうと解釈することにしました。
 もともとメカ屋なので女性の支持を得にくく、作品の評価をしてくれそうな人は最初から全体の半分と思っていいので、半分の75点と考えてもいいんですけどね。それでも私にしてみれば一晩あたりの点数としては快挙です。

 メカ作りに飽きて、たまに気の迷いで無料で配布されているMMDモデルを使って二次創作を作ってみて、評価はともかく閲覧数が急激に伸びるのを見ると「二次創作って強いなぁ」と実感したりもします。自分の技術レベルは自分がよく知っているのですから、一次と二次の比較は容易です。「なんとなく」よりは「自分の肌で感じる」ほうが二次創作の魅力を理解できるはずです。他人のふんどしで相撲をとっているようで、二次創作は受け容れがたいから一次創作一本でいく、など個人的なポリシーはいろいろあるでしょうが、意固地にならず、気張らずにいろいろやってみるのがいいんじゃないでしょうか。要は軸足が動かなければいいことです。

 よく、絵描きの道を登山に例える人がいます。疲れ果ててもう一歩も登れないと思っても足を持ち上げて登り続けてさえいればいずれは高みが見えてくるという論理です。
 私はクリエイターとしてはプロではありませんが、この論理を否定はしません。何も芸術方面に限った話ではないからです。会社員だって楽しいことばかりではありません。自虐ネタっぽいテレビCMがたくさん流れているので、学生さんや会社員を経験したことがない人でも「会社員って大変そうだなぁ」くらいには想像できると思います。つまらない仕事や、できればやりたくない仕事を毎日こなしつつ過ごしています。

 ところがなんですよ。数年も我慢して勤めていれば、いつしか貴重な戦力の一員と考えられるようになります。製品を納品したときに振り返ってみれば新人だった頃の自分よりは遥かに成長していることに気づくのです。
 そのとき、自分にとって大事なのは「がんばった日」だけでしょうか。仕事を投げ出したくなった日や、方々からの理不尽な要求に内心悪態をついていた日や、経験のなさからミスを犯して叱られた日の自分は自分でなかったのでしょうか。
 会社員には客観的に評価してくれる上司という存在が必ずいるので、自分の自己評価が絶対ではないということは自ずとわかるものなのですが、これから上を目指そうとしている絵描きさんにとって客観的な評価をしてくれる人って誰でしょう?

 自分の作品の向こう側にいるエンドユーザー以外にはいません。

 もし、友人や家族など客観的に評価してくれる人がいるならばその方々を大事にしたほうがいいです。顔も名前も知らない他人の指摘は受け入れられなくても身近な人の意見は少々耳が痛くても聞く気になるでしょう。
 でも、そういう人が周りにいない人は? という話になりますね。学生さんならば同好の士なんて学校にいくらでもいそうだと思うのですが、最近はどうもそうでもなさそうです。仮にいたとしても卒業と同時に疎遠になるというのもよくある話です。これは実体験です。

 エンドユーザーが唯一の評価者ならば最初の話に戻っているじゃないか、と言われそうです。自分の気持ちをフラットにするというお話は既にしました。

 では、こう考えましょう。「自分の作品が何回見られたのかわかって、何点だとしても点数がつくだけいい」と。

 期末テストや通知表があるわけでもなし、会社員に点数や科目ごとの五段階や十段階評価なんてありませんからね。営業職の人なら契約件数や売上額で明確に成果が出ますが、技術職の成果の評価は管理職の人がいつも頭を悩ますところです。もし、技術者を誰からの不平不満もなく公平に評価する方法があったらぜひ教えてほしいくらいです。

 悲しいことは、「評価が低いこと」ではなく、「誰も自分の作品を見てくれることもなく、悪評でさえ、誰からも何も評価されないこと」です。そういった意味ではネットで誰でも簡単に自分の作品を展示できる今の環境は恵まれていると思いませんか?

 昔はtwitterやFacebookをはじめとするSNSなんてなかったので、個人でウェブページを作るかコミケのような同人誌即売会に出品するしか作品を公開する方法がなく、アクセス数を稼ぐためにそれはそれは涙ぐましい努力をしたものです。「とにかく見てもらう」だけでも大変な労力を必要としたのです。ウェブサイト間の相互リンクという文化はそういう試行錯誤の中で生み出されたものでした。今では「そういえば、そんなこともしたね(笑)」と笑い話のタネです。Googleをはじめとする検索エンジンの性能が進歩したこともあり、ウェブサイト間のリンクは大して重要ではなくなりました。
 今はニコニコ静画やpixivなどのSNSに勝手に人が集まってくれるのですから、わざわざ自分から方々へ告知してまわる必要がありません。その分、絵を描くことに注力できるのです。

 もちろん、SNSにも良いところばかりではなく功罪両面あります。自分よりもフォロワーが少なかったり、言っちゃ悪いけど自分よりも技術的に拙い作品を描いていても自分よりもたくさん評価されていて、例えばtwitterではリツイートがリツイートを呼び、フォロワー数の数十倍、場合によっては数百倍もリツイートされている作品を見て逆に自信を喪失してしまったという話もうかがったことがあります。
 そういう一見ヘタウマに見える方は、多くの人の興味や共感に作用する心の琴線に触れたか、偶然とは思えないほど何度も続くような場合はそういうのを見つける能力に特段に長けている方なんだろうと思います。こういった傾向は一枚のイラストを専門とする絵描きさんよりも、漫画を描く方に顕著ですが、作画以外の要素も絡んできて話が発散するので漫画の話はひとまず置いておきます。

 「SNSあるある」のようで、少なからず心当たりのある話です。自分のフォロワーほどなぜか自分の作品を他のユーザーに紹介してはくれないものなんですよね。ただ、私自身、フォローしているユーザーの作品をすべて紹介しているわけではありませんし、その方々の作品を見逃したくないからこそフォローしているという側面もあったりして、必ずしも紹介し合うことを約束したものでもないと思い返すとお互い様なのかな、と思ったりもします。
 いずれにせよ、SNSの場合は相互フォローという分子間力のような力学が働いているため、フォロワーの数そのものがその人の人気の指標とは思わないほうがいいかもしれません。
 少なくとも、同じサービスを利用しているのであれば同じ土俵の上ですから、自分の作品より高く評価されている他者のいまひとつな作品をたまたま見つけてしまっても落胆することはないと思います。他の絵描きさんと自分とで数字の多寡を競ったり、単純に比較して一喜一憂するのは意味のないことです。

 それから、もし絵を描いていて嬉しかったことがあったら、それは忘れないほうがいいです。

 私は技師ですから、顧客に技術的な説明をすることがよくあります。他にも私より優秀な技師はいるのに、顧客から指名で質疑の電話がかかってくることもあります。「電話じゃわからないから、資料を持って直接説明しに来い」と言われたときに指名されたりもします。
 正直面倒だな、と思ったりはしますが、相手に理解してもらえたときは満足します。技術的なことを相手にわかってもらえるように簡単に説明するというのは実はとても難しいことだからです。そういうのは上司は結構見ているもので、期末評価に「顧客の信頼を得ている」とただ一言書かれていたときにはそれは嬉しかったものです。報酬などの実益には一切反映されないにもかかわらず、です。

 私は幸運なことに上司に恵まれ、「がんばった私」も「がんばらなかった私」も含めて客観的に評価される環境を得ました。
 じゃぁ、絵描きさんに上司はいるかといえば企業専属のイラストレーターでもない限り、いないことがほとんどだと思います。企業としては固定費を削りたいのが本心ですから、必要なときだけ仕事を引き受けてくれる下請けやフリーランスに外注を出すことを真っ先に考えます。

 顧客というのはえてして発注先のことは褒めません。成果に見合うだけの報酬を支払ったのだから、とわざわざ褒めることには積極的ではありません。特に、「平成不況」と言われるようになった21世紀に入ってからその傾向は顕著になりました。仮にあったとしても、エンドユーザーからの好感触を得た、つまり外注費以上の効果があったときにそれを伝えてくるくらいでしょうか。
 会社員ならなおさらです。企業全体としては高く評価されることはあっても、顧客が個人を名指しで高く評価することはまずありません。もし、そういうことがあったら自慢していいです。たぶん、企業からも表彰されるくらいのレベルです。ほんとに。

 原画家さんのように色塗りを他の人に任せられるほど稀有な技術を持っている人を除けば絵描きさんが絵を描くのは基本的には一人でする作業でしょう。孤独で地道な作業ほど自分の立ち位置は気になるものです。

 でも、逆にこう考えたらどうですか。

 評価が高くとも、低くとも、その評価はあなただけのものです。

 定期テストや通知表から解放されたはいいものの、社会に出てみたら過去のテストの点数や通知表では誰も評価してくれず、誰も関心を持ってくれさえしない「その他大勢」になってみて初めてわかるのですが、自己の持ちうる限りの技量・感性・知識・経験のすべてを注ぎ込んで描き上げた作品を世に問うべくアップロードしたという行動そのものが意義あることなのです。

 何を描いても評価される人気絵師さんを羨ましいと思う気持ちもわからなくはないですが、百人や千人に評価されなくてもいいじゃないですか。一人でも自分の作品を好きだと言ってくれる人がいるならば、その人と自分のために作品を描いてください。私自身、ほとんどそんな姿勢です。自分の好きなものを思う存分作って、誰か奇特な人がそれを気に入ってくれればそれでいいや、と。

 それから、自分の気持ちと作品を大事にしてください。口には出さなかったとしても、自分の作品を自分でけなしたりしないでください。自分の作品を大好きな人の第一号はまず自分であるべきだからです。
 他人から見たら「全然変わってないよ」と言われたとしても、自分自身でどんなに些細なことでもいいので「以前よりここが上手くなった!」と発見することです。
 もし、その第一号が作品をけなしてしまったら、創作の動機そのものが揺らいでしまいませんか。

 確かに、今は二十年前では考えられなかったほど高性能のパソコンやスキャナ、ペンタブレットといった機材が安価になって、本職も趣味も含めたイラストレーターそのものの母数が昔に比べると遙かに大きくなったことと、プロフェッショナルがアマチュアの目の届くところに降りてきてくれているので、エンドユーザーである一般視聴者は近寄ってきてくれたプロフェッショナルに注意を向けていて、アマチュアが個人的なお褒めの言葉をいただくことは稀になりました。
 昔はプロはプロだけの雲上の世界のようなところにいて一般人が言葉を交わす機会などない、というのが常識みたいな感じだったので、アマチュアでも結構、直接電子メールで感想なり批判なり反響が来たものです。しかし最近は、ネットの情報が膨大になったことに加え、個人情報保護意識が高くなったのも相まって本当に何も来ません。見た人を笑わせるためだけのネタ絵じゃないと匿名SNSでもコメントのひとつもないくらいです。

 だからこそ、自分にとっては耳の痛い話だとしても作品への感想や指摘は大事にしてほしいし、言われて嬉しかったことは「どうせ社交辞令なんでしょ」なんてうがちすぎた見方をせず、素直に受け止めていつまでも覚えていてほしいと思うのです。プロフェッショナルから見れば吹けば飛ぶようなものかもしれませんが、それがささやかな自信になり、次なる作品を制作するモチベーションになります。


 最後になりますが、「継続は力なり」と言います。続けることは大変苦しいことですが、続けていなければどんどん進んでいく周囲に対して相対的に遅れていってしまうのが世の常です。なんでもそうですが、年単位のブランクがあるとすぐに腕は鈍ってしまいます。

 私自身、就職してから日々の業務に明け暮れる毎日となり、まったく絵を描かなくなってしまい、十数年経ってから大変後悔しています。今ほど3DCGが一般的ではなかった頃、一時は雑誌編集部から記事の執筆を依頼されたりしていたので、本業との両立を真剣に考えていれば今頃はもっと違う自分がいたかもしれないと思うと実にもったいないことをしました。

 もし、他人からどう言われようとも絵を描くのが好きなのであれば、ぜひお続けになってください。毎日は続けられなくても、疲れて少し休んでしまっても、落書きでもいいのでどうか描き続けてください。私のように過去の自分を振り返った時に後悔しないように。

 だいぶ前のことになりますが、偶然ネットで、「もう絵を描くのをやめてしまおうか」と真剣に悩んでいる方の一言を見たことがあります。その方の作品の、その方らしさが溢れたタッチがとても好きだったので、「私ごときが何を言っても」と思いつつも、ろくに話したこともないのを承知で直接メッセージを送らせてもらって強く慰留させていただきました。私の言葉が奏功したなどと自惚れるわけではありませんが、その方は幸いにも今も何らかの形で絵を描き続けておられるようで、ネットも捨てたものではないな、と思ったことがあります。

 この記事を最初に書いた頃、自分でもまったく予想していなかったことから考える時間をたくさん与えられることになり、「私の好きだったことってなんだろう」と思い返した時にもう一度創作活動に関わることを今更ながらに思いついた次第です。年齢的に遅きに失した感は否めませんし、若い方たちのみずみずしい感性にはかなうことなどないと承知のうえで、「私の好きなものはこういうものだ」と主張せずにはいられなくなったのです。上では随分偉そうなことを書きましたが、描きたいと思う好きな物がないことには創作活動の動機になりませんから、まずは自分の好きな物を見てもらうことからスタートだと思ったのです。

 まだまだ趣味の範囲を出ていませんから、私が創作活動をしていなかった十数年の間、イラストや3DCGを一筋にやってきた方々の作品とは比べものになりませんが、時折いただく「いいね」にささやかながらモチベーションをもらっている今日この頃です。

(リクエストがありましたので、旧ブログの記事を転載・加筆しました。)

MediaWikiのキャッシュを有効にする

最終更新:2016/09/06

MediaWikiをインストールしてから結構経ったけど、キャッシュを有効にしてなかったことに今更気がついた。ページひとつ更新するにも結構待つし、ファイルをまとめて10個くらいアップロードするとなるとかなりの時間になる。

そこで、多少なりともレスポンスが速くなればいいなぁ、と思い、サーバー側のキャッシュを有効にしてみることにした。MediaWiki公式サイトの説明をざっくり読んでみてからネットを検索したらいくつか記事が見つかった。

具体的には、LocalSettings.phpの次の設定を追加又は変更する。

$wgMainCacheType = CACHE_ANYTHING; /* default: CACHE_NONE; */
$wgUseFileCache = true;
$wgCacheDirectory = "$IP/cache";
$wgShowIPinHeader = false;
$wgEnableSidebarCache = true;

この記事を書いている時点で最新バージョンのMediaWiki 1.24.2では、$wgUseFileCacheを true にすると、$wgShowIPinHeaderは自動的に false になるので設定する必要はないんだけど、念のため。

$wgCacheDirectoryは特別な理由がない限り、"$IP/cache"でいいと思う。英語用のキャッシュが約620KB、日本語用のキャッシュが約708KBくらい生成されてたけど、思ったよりは大きくはなかった。しばらく運用してみてどのくらいになるのか観察することにする。

試しに、いくつかファイルをアップロードしてみたけど、目に見えてレスポンスが良くなった。日本語版ウィキペディアの記事を更新するくらいのレスポンスにはなったように思う。ベンチマークで厳密に計って比較したわけではないけど、体感的に速くなったと感じられれば目的は達成。こんなことなら、もっと早くキャッシュを有効にしておくべきだった。

参考記事

MediaWikiのアップグレード手順

最終更新:2016/09/06

いつの間にか、MediaWikiが1.23にアップデートされていた。1.22でもとりあえず困ってはいないんだけど、セキュリティの問題もあるし、いざという時にメンテナンスできないと困るので、練習のつもりでアップグレードに挑戦してみることにした。

MediaWikiの公式サイトにもアップグレード・マニュアルはあるんだけど、あらゆるバージョンや環境のことを網羅しようとした書き方になっているので、わかりやすいとは言えない。

さくらのレンタルサーバにMediaWikiをインストールしているという前提で、ざっとまとめてみた。おおまかに言うと、手順は次のとおり。

  1. 現在のデータベースのバックアップ
  2. 現在のMediaWikiのバックアップ
  3. 新しいMediaWikiのダウンロード
  4. 新しいMediaWikiの展開
  5. 新しいMediaWikiを現在のMediaWikiに上書き
  6. データベースを新しいMediaWikiに適合させる

具体的なコマンドは次のような感じ。SSHにログインを参考にSSHシェルにログインして実行する。

mysqldump -h [host-name] -u [user-name] --password=[your-pass] --xml [dbname] > backup.xml
cd www
tar cvzf mediawiki.backup.tar.gz [wiki-directory]
wget http://download.wikimedia.org/mediawiki/1.23/mediawiki-1.23.1.tar.gz
tar xvzf mediawiki-1.23.1.tar.gz
cp -a mediawiki-1.23.1/* /home/[user-name]/www/[wiki-directory]/.
cd [wiki-directory]/maintenance
php update.php

[2016年2月13日追記]

MediaWikiのダウンロードの方法が変わって、HTTPS接続でないとデータを取得できなくなった。また、普通にダウンロードしようとすると証明書関連の問題でアクセスを拒否されることがあるので、--no-check-certificateオプションを追加した(チェックを省略するので、自己責任で!)。また、XML形式でのバックアップはSQLデータベースサーバーに書き戻す時に問題が多々発生することがわかったので、SQL形式でバックアップするように少し見直した。

mysqldump -h [host-name] -u [user-name] --password=[your-pass] [dbname] > backup.sql
cd www
tar cvzf mediawiki.backup.tar.gz [wiki-directory]
wget https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.2.tar.gz --no-check-certificate
tar xvzf mediawiki-1.26.2.tar.gz
cp -a mediawiki-1.26.2/* /home/[user-name]/www/[wiki-directory]/.
cd [wiki-directory]/maintenance
php update.php

[2016年3月13日追記]

更にバックアップまわりを見直し。mysqldump--default-character-set--hex-blobの各オプションを追加した。

--hex-blobオプションは、バイナリカラムを16進数表記でダンプする。例えば、'abc'という文字列のバイナリは0x616263という文字列に変換される。ファイルサイズは大きくなるけど、特殊な文字を使っている場合のデータの欠落を防止することができる。

SQL形式のバックアップ・ファイルからデータベースにインポートできれば、元の状態を完全に復元できる。ただし、MySQLのバージョンが違っていたり、MediaWikiのバージョンが違っていてデータベース構造が変わっていたりすると復元できない可能性が高い。サーバーの引っ越しのためというより、同一サーバー、同一MySQL、同一MediaWikiにおける原状復帰のためのバックアップ・ファイルと割り切ったほうがいい。

念のため、MediaWikiのメンテナンス・スクリプトであるdumpBackup.phpを使用して全記事の全部の版をXML形式でダンプしておくコマンドを追加した。--fullオプションが全名前空間の全記事の全部の版を指定している。

このダンプでバックアップできるのは各種名前空間を与えられた文字だけのページだけで、画像などのメディア・ファイルはバックアップされない。また、データベース全体を復元させることはできないので、rebuildrecentchanges.phpといった別のメンテナンス・スクリプトを実行してテーブルに反映させる必要がある。手間はかかるが、MediaWikiのバージョンが変わっていても復元できる可能性が高いという利点がある。

mysqldump -h [host-name] -u [user-name] --password=[your-pass] --default-character-set=binary --hex-blob [dbname] > backup.sql
cd www/[wiki-directory]
php maintenance/dumpBackup.php --full > backup.xml
cd ..
tar cvzf mediawiki.backup.tar.gz [wiki-directory]
wget https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.2.tar.gz --no-check-certificate
tar xvzf mediawiki-1.26.2.tar.gz
cp -a mediawiki-1.26.2/* /home/[user-name]/www/[wiki-directory]/.
cd [wiki-directory]/maintenance
php update.php

dumpBackup.phpでダンプしたバックアップは、importDump.phpというメンテナンス・スクリプトで書き戻すことができる。--dry-runオプションをつけることで、XMLの解析だけして実際にはデータベースには反映せず、MediaWikiで受け付けられるバックアップ・ファイルかどうかをテストすることができる。

cd www/[wiki-directory]
php maintenance/importDump.php --dry-run < dumpBackup.xml

実行すると、次のようにメッセージが表示される。

100 (131.18 pages/sec 207.26 revs/sec)
200 (219.45 pages/sec 283.09 revs/sec)
300 (229.85 pages/sec 286.54 revs/sec)
400 (279.63 pages/sec 334.86 revs/sec)
Done!
You might want to run rebuildrecentchanges.php to regenerate RecentChanges

参考記事

CITIZEN ATTESA BY0045-66F

最終更新:2016/09/06

91S86LzijCL._SL1500_久しぶりに腕時計を買った。それこそ10年ぶりくらいに。iPhoneを買うまでは折り畳み式の携帯電話(いわゆるガラケー)が時計代わりで、片手でもすぐに時刻を確認できたので、腕時計をわざわざ身に付ける必要性がかなり薄れていたから。

ところが、iPhoneのタッチパネル式液晶ディスプレイを保護するためにスナップで蓋をするタイプのカバーを使っている関係上、両手を使わないと時刻を確認できなくなった。iPhoneのパネル表面はガラスなので当たりどころが悪いと簡単に割れるし、AppleCareでも水没同様保証が効かないので用心に越したことはない。保護フィルムはうまく貼れた試しがないので好きではない。

そんなわけで、雨の日で傘をさしている時や、荷物が多い時、満員電車の中などでは時刻を確認するのにもひと手間かかるようになった。iPhoneには今のところ防水機能がないので荒天の時は時刻を見ることすらためらわれる。そして、何よりも、iPhoneは電池が1日くらいしかもたないので、充電しなくても2、3日は使えたガラケーの携帯電話と比べても時計としては心許ないのだ。

どうせ買うなら、時刻合わせの必要がなくて、電池切れの心配もないソーラー電波時計にしようと色々と見ていたのだけど、価格が比較的手頃なものは本当に時刻がわかるだけ、という見た目にもあまりおもしろくない時計が多かった。

デザインが優れた輸入品の腕時計は、宝飾品としての側面もあるため機械式がほとんど。電波時計や太陽電池駆動といった面倒くさがりな割には時間にシビアな日本人好みの機能は備えていない。機械式はもちろんのことだけど、電池式でも電波時計や太陽電池駆動は皆無と言っていい。

太陽電池駆動でも二次電池(充電池)には寿命があり、その頃には互換性のある二次電池を製造していない可能性がある。時計メーカー各社も、特に電池式はメンテナンスを前提としていないので、二次電池の寿命が時計の寿命とほぼ同義と言っていい。一方で、機械式時計は適切な手入れと定期的なオーバーホールをすることを前提としていて、故障していたとしても部品の図面等のデータが残ってさえいれば(お金をかければ図面がなくても)機能を回復できるため、宝飾品やステータスとしての半永久的な価値を求める海外の時計メーカーに好まれる。

少し前までスーパークォーツ式腕時計を作っていたブライトリングも機械式一本に絞ってしまったので、選択肢は国産しかないんだけど、国産はとにかくデザインが野暮ったい。デザインとエンジニアリングは別物と考える日本人の悪癖が顕著に見える(日本製は安くて高性能、故障が少なく堅牢で機能的だと絶賛する外国人はもちろんいるけど)。

掃除機で著名なダイソン社のジェームズ・ダイソン氏が言っていたことだけど、「エンジニアはすべからくデザイナーとエンジニアを兼務したデザイン・エンジニアであるべきだ」という意見はもっともだと思う。日本のエンジニアは設計や製造上の都合をデザインにしわ寄せしてしまうのをやめるべきだと思う。

そんな中でも異彩を放っていたのは、シチズンのアテッサ・シリーズのBY0045-66Fというモデル。

文字盤に太字のアラビア数字で偶数だけ盛り上げて刻印してあって、数字の表面処理も意図的に粗くしてある。立体的なデザインの文字盤が気に入った。立体的といえばセイコーのアストロン・シリーズもあるけど、文字盤が深すぎて角度によっては時刻が読みにくいのが欠点。

ベゼルにも偶数時方向に溝を切られているだけで、タキメータのような計算尺的な普通は使わない(使い方がよくわからない)機能を載せていないのもポイントが高い。真っ黒なベゼルは1998年に世の中の話題をさらったBVLGARI DIAGONO ALUMINIUMを思い起こさせなくもない(欲しかったけど、当時は高くて買えなかった)。

昔のソーラー時計は黒い太陽電池パネルがどこかにあったのでわかりやすかったけど、技術の進歩もあって最近の時計では文字盤が光を透過するようになっていてパネルをほぼ完全に隠してしまえるようになっている。そこをあえて格子状の溝を切り、一見した時は「太陽電池パネルがむき出しなのかな」と思ったほどの無骨さをデザインの一部に繰り入れている。

いわゆる万年カレンダーのパーペチュアルカレンダーが3時方向ではなく、4時方向に斜めに配置されているのもいい(ムーブメントの型が同じならみんな4時方向だけど)。ワールドタイムの都市表示も前後の都市名が見えるという、特に意味はないんだけど一時期流行ったスケルトンデザインの香りもするメカニカルっぽさにも惹かれた。

ただ、定価が15万円と国産の中では高級時計の部類に入るので、ちょっと躊躇していた。限定生産モデルでこの機会を逃すと次がないのはわかっていたけど、すべての発端であるiPhoneをも遙かに上回る価格の腕時計が果たして必要なのだろうか、と。

でも、同様の機能を備えた(もっと言うとまったく同じムーブメントの)最新モデルでは文字盤にアラビア数字が刻印されているものはなく、こういったタイプはしばらく出ないかもしれないと判断したことと、2013年夏モデルなので発売からかなり経っていてAmazonをはじめとして在庫がなくなる店舗が多くなってきたことにも蹴飛ばされ、買うことにした。清水の舞台から飛び降りる心地というのはこういうものなのだろうか。

同じモデルで文字盤の文字やスイッチ類が金色のものもあるんだけど、使えるシチュエーションが限られそうなので、普段使いはもちろんのこと、ビジネスにもフォーマルにも使えそうな銀色を選んだ。

IMG-2014-05-16-0307IMG-2014-05-16-0312

実物を手にしてみると、竜頭が二段階に引き出せたり、竜頭の回転とボタン操作を組み合わせて各種機能を操作するインターフェースには少々戸惑ったけど、二次電池の残量確認や標準電波の強制受信といった普段使いそうな機能はすぐに覚えられるくらいに極力簡単な操作になっていた。普段は時刻を示している針が各種設定時には逆回転したりして何かの機械の計器のように動くのは単純に楽しい。この辺は機械式時計にはない楽しみかもしれない。

一見してわかるようにクロノグラフだけど、中心に回転軸を持っている一番長くて細い針がクロノグラフの計測用秒針になっている。0.2秒刻みになっているので、大きい文字盤で見た方が正確に読めるし、計測の度にゼロ位置(12時の位置)に戻す必要がないから、というのが理由らしい。それが最近のクロノグラフの世界的主流だそうだけど、普通の壁掛け時計や目覚まし時計などで言うところのいわゆる秒針が普段は動かないというのも若干違和感はあるので、少し慣れが必要かな、と感じた。秒針代わりにクロノグラフを動かしたままにしておくのは動力の無駄になる上にムーブメントにも負荷をかけるのであまりおすすめできないそうな。使用者のお好みで時刻用秒針とクロノグラフ用秒針を入れ替えられたら良かったんだけど、さすがにそれは高望みしすぎかな。

後で調べてみてわかったことだけど、同じシチズン製でもセンター秒針がクロノグラフ秒針と時刻の秒針を兼ねていて、2時方向の機能針がクロノグラフ分針と1/20秒針になっているムーブメント(シチズンではキャリバーと呼んでいる)はあるようだ。ただ、取扱説明書を見る限り、竜頭を一段引いてから回してモード選択針でクロノグラフモードを選択して秒針をゼロ位置に戻した後、竜頭を元の位置に戻してからスタートボタンを押して計測を開始するという操作になっていた。おそらく文章にすると余計にわかりにくくなるだろうけど、ボタンひとつでクロノグラフ計測を開始できるこのモデルよりも遙かに煩雑と言えた。

クロノグラフ計測なんて滅多に使わないよ、と思う人も大勢いるだろうし、好みの問題かもしれないけど、これはこれで合理的に設計されているのだと理解した。理解できたら、センター秒針が動かないほうがなんか格好良く思えてきた(単純)。

参考記事

iPad/iPhoneでMediaWikiのロゴが英語版ウィキペディアになってしまう問題

最終更新:2016/09/06

ある時から、自分のウィキをiPadやiPhoneで表示しようとすると、MediaWikiのロゴがオリジナルのものから英語版ウィキペディアのものに変わってしまって、不思議に思っていた。PCで表示する分にはどのブラウザでも正常に表示される。しかも、iOSに標準でインストールされているSafariだけではなく、Chromeでも同じ問題が起こる。PC版のブラウザと違って要素解析ができないので、しばらく原因がわからず問題を放置していた。ところが、MediaWikiのサポートデスクの該当スレッドを注意深く読んでみると、最後のほうに#p-logoというidセレクタをもう一度確認してみよう、という一文があった。

当初は「iOSのバージョンが古いんじゃない?」とか「単純にキャッシュの問題じゃないの?」といった回答が多かったので、そういうものなんだろうかと思って最後まで読んでなかった。

原因は、ウィキペディア風の外観にするためのMediaWiki:Common.cssをコピーして移設したことにあった。最後のほうに、モバイル端末向けの表示用に次のようなCSSが記述されている。確かに、英語版ウィキペディアのロゴ・ファイルをダイレクトで呼び出しているので、iPadやiPhoneでロゴが変わってしまうのは当然だった。

/* [[MediaZilla:35337]] */
@media (-webkit-min-device-pixel-ratio: 1.5), (min--moz-device-pixel-ratio: 1.5), (min-resolution: 1.5dppx) {
        #p-logo a {
                background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Wikipedia-logo-v2-en.svg/204px-Wikipedia-logo-v2-en.svg.png") !important;
                background-size: 136px auto;
        }
}
@media (-webkit-min-device-pixel-ratio: 2), (min--moz-device-pixel-ratio: 2), (min-resolution: 2dppx) {
        #p-logo a {
                background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/b/b3/Wikipedia-logo-v2-en.svg/270px-Wikipedia-logo-v2-en.svg.png") !important;
                background-size: 135px auto;
        }
}

ウィキペディアのロゴはウィキメディア財団が著作権を持っているので、まったく無名のウィキだけど、このまま放置しておくのは賢明ではない。これを、次のように書き換える。

/* [[MediaZilla:35337]] */
@media (-webkit-min-device-pixel-ratio: 1.5), (min--moz-device-pixel-ratio: 1.5), (min-resolution: 1.5dppx) {
        #p-logo a {
                background-image: url("//[domain]/[wiki-directory]/images/b/bc/Wiki.png") !important;
                background-size: 136px auto;
        }
}
@media (-webkit-min-device-pixel-ratio: 2), (min--moz-device-pixel-ratio: 2), (min-resolution: 2dppx) {
        #p-logo a {
                background-image: url("//[domain]/[wiki-directory]/images/b/bc/Wiki.png") !important;
                background-size: 135px auto;
        }
}

~/images/b/bc/ というディレクトリは、ウィキにファイルをアップロードするとMediaWikiが自動的に生成するもので、画像などの格納に使うもの。各自の環境によって異なるので、目的の画像を自分のウィキで表示させた上で右クリックしてURLを確認する。管理者権限を有するユーザーが削除しない限り、新しいバージョンのファイルをアップロードしても過去のバージョンは残るため、URLが一意に定まることを利用する。

このように指定しておけば、ロゴを変更したくなった時は、FTP転送ではなく、ウィキからHTTP経由でアップロードしてデータベースを書き換えてやることで簡単に対応できるし、将来MediaWikiがバージョンアップした際にアップグレードした場合でもロゴのファイルを上書きされなくて済む。MediaWiki:Common.cssはそもそもデータベース上に存在するものなので、MediaWikiのソフトウェアのアップグレードには直接影響を受けない。

MediaWikiにExtension:Scribuntoをインストール

最終更新:2016/09/06

さくらインターネットのレンタルサーバでMediaWikiを動作させている前提で、Extension:Scribuntoをインストールする。Scribuntoは、Luaという言語で書かれたスクリプトを実行する環境をMediaWikiに追加設定する拡張機能。シンプルに使う分にはなくても特に困らないけど、Wikipedia英語版やWikimedia Commonsからテンプレートをインポートしたい場合はかなりの確率で必要になる。

Lua 5.1.4

Extension:Scribuntoは単体では動作しないので、Luaというプログラミング言語を解釈するインタープリターが必要になる。さくらインターネットではサーバのOSにFreeBSDを使用していて、SourceForgeで提供されているWindows用やMac用のLuaバイナリではうまく動作しない。Extension:Scribuntoのアーカイブに /extensions/Scribunto/engines/LuaStandalone/binaries という思わせぶりなフォルダが事前に用意されているけど基本的に役に立たない。そこで、Lua Download areaから lua-5.1.4.tar.gz のソースコードをダウンロードし、解凍後、makeして直接サーバにインストールする。

2016年3月7日現在、Luaの最新バージョンは5.3.2になっているが、Lua 5.2.xやLua 5.3.xを使用すると「ステータス1」を返してインタープリターがエラーを起こすことがある模様。なお、Lua 5.1.xではLua 5.1.5が最終バージョン。

具体的には、SSHにログインを参考にSSHシェルにログインし、コマンドラインから次の手順で行う。あからじめ/local/src/というディレクトリをサーバに作っておく(これだけはFTPクライアントでもできる)。

cd ~/local/src/
wget http://www.lua.org/ftp/lua-5.1.4.tar.gz
tar -zxvf lua-5.*
cd lua-5.1.4
make freebsd
make local
cd bin
ln -s lua lua-5.1.4

Extension:Scribuntoの実装

Extension:Scribuntoのスナップショット(現時点で安定動作する最新版)をMediaWiki公式サイトからダウンロードし、適当なフォルダに解凍する。/extensionディレクトリに/Scribuntoディレクトリを作成し、そこへFTPクライアントでアップロードする。

LocalSettings.phpに次の6行を追加する。Luaインタープリターはユーザーが指定できるもっともルートに近いところから順にパスを指定しなければならないので注意(他の環境変数のように$IP/~では始められないということ)。

require_once "$IP/extensions/Scribunto/Scribunto.php";
$wgScribuntoDefaultEngine = 'luastandalone';
$wgScribuntoEngineConf['luastandalone']['luaPath'] = '/home/[user-name]/local/src/lua-5.1.4/bin/lua-5.1.4';
$wgScribuntoEngineConf['luastandalone']['errorFile'] = '/home/[user-name]/www/[wiki-directory]/extensions/Scribunto/errorfile.log';
$wgScribuntoUseGeSHi = true;
$wgScribuntoUseCodeEditor = true;

メインページを再読み込みすると、「モジュール」、「モジュール・トーク」という名前空間が追加され、Luaで書かれたスクリプトを実行できるようになる。

なお、4行目はLuaインタープリターのエラーログの設定で、正常に動作するようになったらコメントアウトするなどして無効にしてもOK。5行目は、各種言語の文法(マークアップ)をハイライトするExtension:SyntaxHighlight_GeSHiを、6行目は、CSSやJavaScriptの編集を補助するExtension:CodeEditorをそれぞれLua言語で書かれたスクリプトモジュールでも有効にする設定。

もし、スクリプトを保存しようとした時に、

Script error: Lua error: Internal error: The interpreter exited with status 127
Script error: Lua error: Internal error: The interpreter exited with status 126

といったエラーメッセージが出る場合は、インタープリターのmakeに失敗しているか、パスが間違っている可能性がある。上の手順でインタープリターをmakeした場合は自動的に実行可能なパーミッションが与えられているので特に問題にならないけど、手順が間違っていないのにうまくいかない場合はインタープリターのバイナリファイルのパーミッションが「755」など全ユーザーが実行可能になっていることを確認する。

インタープリターが正常に動作しているかどうかテストするには、Wikipedia英語版にあるModule:Bananasという極シンプルなスクリプトを自分のWikiにコピーして同名で保存してみる。保存時に文法エラーがないかチェックされるので、正常に動作していれば、何事もなく保存できる。

{{int:Lang}}の問題を解決

メディアウィキ・コモンズからテンプレートを移入しようとすると、必ずと言っていいほど言語間の翻訳の問題が出てくる。メディアウィキ・コモンズは、各言語ごとに英語の原文を翻訳した膨大なシステム・メッセージを持っており、閲覧者の環境(またはプリファレンス・個人設定)に合わせて置き換えたうえで出力してくれる。ところが、そういった言語自動切換え機能を備えたテンプレートをそのまま実行(トランスクルード)しようとするとModule:FallbackModule:Languagesといったモジュールでスクリプト・エラーが出る。これは、{{int:Lang}}というマークアップを使ってMediaWikiに標準で実装されていないシステム・メッセージを呼び出そうとしているから。MediaWikiは、Langというキーワードに結び付けられたシステム・メッセージを見つけられない場合は<Lang>という文字列を返してくる(詳しくはHelp:マジックワード参照)。これでは、ISO 639で定められた2文字の言語記号には当たらないのでエラーになって当然ということになる。

これを解消するには、自分のウィキにMediaWiki:Langというファイルを作り(作り方は標準記事名前空間と同じなので特に説明はしない)、「ja」(日本語)や「en」(英語)などとシンプルにISO 639で定められた2文字の言語記号を書いて保存する。

システム・メッセージの反映には少し時間がかかるので、すぐに確認したい場合は、エラーが出たテンプレートを編集モードで開いて何も変更せずにプレビュー機能を使い、スクリプト・エラーが出ないことを確認する(関係するテンプレートやモジュールを全部展開して解釈するので数十秒かかる)。遅くとも、一晩経てばシステム・メッセージは全体に反映されるようになっている。

モジュール名前空間の接頭辞変更

モジュール名前空間はデフォルトでは「モジュール」、「モジュール・トーク」となっている。私はUTF-8でのURLがわかりにくいという理由ですべての名前空間を英語に戻してしまったので、同様に英語に統一したい。そこで、/extension/Scribuntoディレクトリの直下にあるPHPファイルScribunto.namespaces.phpを次のように変更する。例は、日本語のWikiを対象とする場合。

なお、しつこいようだけど、UTF-8を編集できるエディタでないとファイルが破損するので、必ずUTF-8が編集できるエディタを使用する。

$namespaceNames['ja'] = array(
	828 => 'Module',
	829 => 'Module_talk',
);

参考記事