------------------------------------------------------------------------------- 　　　　　　　POV-Ray 3.0 の日本語版マニュアル暫定第5.2版について M.Takatera(takatera@ted.shinshu-u.ac.jp) ------------------------------------------------------------------------------- This Japanese version of Documentation was translated unofficially by some volunteer persons. The POV-Ray team(tm) is not responsible for supporting this Japanese Documentation. これは非公式に翻訳されたものです。 翻訳についてはPOV-Teamがサポートするものではありません。 オリジナルのドキュメントは下記の公式サイトから入手した povdoc.zip:PORAY.DOC 1997/2/6 15:13 です。 POV-Ray 3.0の公式のフルパッケージは http://povray.org/ftp/pub/povray/Official-3.0/index.html より入手できます。 本テキスト版には図は含まれていません。図の挿入位置は<>内にhtml版のgifファイル名およびpovファイル名で示してあります。また()内の図のファイル名は旧3.0.10版で使われていたものです。 オリジナルのテキスト版はhtml版で表になっている部分が一部欠落していますのでhtml版より補いました。 本翻訳を利用した結果に関して訳者らはなんら責任を負うものではありません。 利用はあくまでも個人の責任で参考にしてください。 Masayuki Takatera(takatera@ted.shisnhu-u.ac.jp) 翻訳者および協力者 Akira Sasaki(akira@cup.com) 　　　Komuro Hideaki(kom@super.win.or.jp) Masayuki Takatera(takatera@ted.shisnhu-u.ac.jp) Yoshishige Arai(ryo2@on.rim.or.jp) 改版履歴 暫定第5.2版1997 10/20:誤字脱字の修正 暫定第5.1版1997 2/23:誤字脱字の修正、6.2.2.4.3の訳出 暫定第5版 1997 2/20: POV-Ray 3.01版のドキュメント追加部分を加える。 暫定第4.1版1997 1/ 9: 図のファイル名を追加 暫定第4版 1997 1/ 3: 暫定日本語化全訳版。 暫定第3版 1996 11/18: 5章および6章の追加。 暫定第2版　1996 11/13: 用語および訳の見直し。4章までの欠落部の訳出。目次の追訳 ------------------------------------------------------------------------------- これは暫定版であり再配布，他の場所での一切の公開を禁止します。 ------------------------------------------------------------------------------- Persistence of Vision(tm) Ray-Tracer (POV-Ray(tm)) User's Documentation 3.0 Copyright 1997 POV-Team(tm) (訳注:POV-Ray 3.0.1で大きな追加変更があったセクション番号には*を付けた) 1 序 1.1 表記法 2 本プログラムについて 2.1 レイトレーシングとは何か? 2.2 POV-Rayとは何か? 2.3 あなたはどのバージョンのPOV-Rayを使うべきか? 2.3.1 IBM-PC とその互換機 2.3.1.1 MS-DOS 2.3.1.2 Windows 2.3.1.3 Linux 2.3.2 Apple Macintosh(アップルマッキントッシュ) 2.3.3 Commodore Amiga(コモドールアミガ) 2.3.4 SunOS 2.3.5 一般のUnix(Generic Unix) 2.3.6 すべての版について 2.3.7 POV-Rayのコンパイル 2.3.7.1 ディレクトリ構造 2.3.7.2 POV-Rayのソースを構成する 2.3.7.3 まとめ 2.4 POV-Rayのファイルはどこにあるか 2.4.1* CompuServのPOVRAYフォーラム 2.4.2 インターネット 2.4.3 America On-LineのPC Graphics Area 2.4.4 El Cerrito, CA の The Graphics Alternative BBS 2.4.5 PCGNet 2.4.6 POV-Rayに関する書籍およびCD-ROM 3 クイックスタート 3.1 POV-Rayのインストール 3.2 基本的な使用法 3.2.1 他のディレクトリにあるファイルの実行 3.2.2 INI ファイル 3.2.3 POVRAY.INIに代わるもの 3.2.4 バッチファイル 3.2.5 ディスプレイタイプ 4 POV-Ray 初心者向けの手引き 4.1 われわれの最初のイメージ 4.1.1 POV-Rayの座標系を理解する 4.1.2 標準インクルードファイルの追加 4.1.3 カメラを追加する 4.1.4 オブジェクトを追加する 4.1.5 オブジェクトにテクスチャを加える 4.1.6 光源を定義する 4.2 カメラを使う 4.2.1* 焦点ぼけを使う 4.3 単純な形状 4.3.1 ボックスオブジェクト 4.3.2 コーンオブジェクト 4.3.3 円筒オブジェクト 4.3.4 平面オブジェクト 4.3.5 標準インクルードオブジェクト 4.4 高度な形状 4.4.1 双三次パッチオブジェクト 4.4.2* ブロブ(Blob)オブジェクト 4.4.2.1* コンポーネント型と他の新しい機能 4.4.2.2* 複雑なブロブ構造と負の強度 4.4.3 ハイトフィールドオブジェクト 4.4.4* レイズ(Lathe:ろくろ、旋盤)オブジェクト 4.4.4.1* スプラインの概念を理解する 4.4.5 メッシュオブジェクト 4.4.6 ポリゴンオブジェクト 4.4.7* プリズムオブジェクト 4.4.7.1* 古いスプラインの新しい秘訣を教える 4.4.7.2* なめらかな変化 4.4.7.3* 複数の副次形状 4.4.7.4* 円錐スウィープと先細り効果 4.4.8 超2次楕円体オブジェクト 4.4.9 回転面オブジェクト 4.4.10 テキストオブジェクト 4.4.11 トーラスオブジェクト 4.5 CSG オブジェクト 4.5.1 CSGとは何か? 4.5.2 CSG結合(和、ユニオン) 4.5.3 CSG交差(積、インターセクション) 4.5.4 CSG差(ディファレンス) 4.5.5 CSG併合(マージ) 4.5.6 CSGの落とし穴 4.5.6.1 一致表面 4.6 光源 4.6.1 環境光源 4.6.2 点光源 4.6.3 スポットライト光源 4.6.4 円筒光源 4.6.5 面光源(エリア光) 4.6.6 オブジェクトを光源に割り当てる 4.6.7 光源の特別な記事 4.6.7.1 影のできない光を使う 4.6.7.2 ライト・フェイディング(光の溶暗、溶明)を使う 4.6.7.3 光と大気(Atmosphere) 4.7 簡単なテクスチャオプション 4.7.1 表面の仕上げ 4.7.2 凹凸を加える 4.7.3 カラーパターンの作成 4.7.4 定義済みのテクスチャ 4.8 高度なテクスチャオプション 4.8.1 ピグメントと法線パターン 4.8.2 ピグメント 4.8.2.1 カラーリストピグメントを使う 4.8.2.2 ピグメントとパターンを使う 4.8.2.3 パターン修飾語を使う 4.8.2.4 透明ピグメントと階層化テクスチャを使う 4.8.2.5 ピグメントマップを使う 4.8.3 法線(Normal) 4.8.3.1 基礎的な法線修飾語句を使う 4.8.3.2 法線を混合する 4.8.4 仕上げ(フィニッシュ) 4.8.4.1 環境光を使う 4.8.4.2 表面ハイライトを使う 4.8.4.3 反射とメタリックを使う 4.8.4.4 屈折を使う 4.8.4.5 光の減衰を付け加える 4.8.4.6* 模造された火線を用いる 4.8.4.6.1* 火線とは何か? 4.8.4.6.2* シーンに火線を適用する 4.8.4.6.3* 火線と法線 4.8.4.7 虹色の光彩を用いる 4.8.5* ハロー(光輪・光暈) 4.8.5.1 ハローとは何か? 4.8.5.2 放射(Emitting)ハロー 4.8.5.2.1 基礎的なハローから始める 4.8.5.2.2 輝度を増やす 4.8.5.2.3 いくらかの動乱を加える 4.8.5.2.4 ハローのサイズ変更 4.8.5.2.5 リアリズムを改善するためにFrequencyを使う 4.8.5.2.6 ハローの色を変更する 4.8.5.3 グローイング(白熱)ハロー 4.8.5.4 減衰(Attenuating) ハロー 4.8.5.4.1 雲を作る 4.8.5.4.2 ハローコンテナのスケーリング 4.8.5.4.3 付加的ハローを加える 4.8.5.5 ダスト(Dust)ハロー 4.8.5.5.1 スポットライトに照らされたオブジェクトから始める 4.8.5.5.2 ダストを加える 4.8.5.5.3 ダストの密度を減らす 4.8.5.5.4 見かけのよい影を作る 4.8.5.5.5 動乱を加える 4.8.5.5.6 色付きのダストを使う 4.8.5.6 ハローの落とし穴 4.8.5.6.1 ハローが許される場所 4.8.5.6.2 コンテナオブジェクトを重ねる 4.8.5.6.3 複数の減衰ハロー 4.8.5.6.4 ハローと中空オブジェクト 4.8.5.6.5 ハローコンテナのスケーリング 4.8.5.6.6 サンプリングレートの選択 4.8.5.6.7 動乱(Turbulence)を使用する 4.9* 特殊テクスチャを用いた作業 4.9.1* ピグメントマップを用いた作業 4.9.2* 法線マップを用いた作業 4.9.3* テクスチャマップを用いた作業 4.9.4* リストテクスチャを用いた作業 4.9.5* タイルって何? 4.9.6* 平均関数 4.9.7* 階層化テクスチャを用いた作業 4.9.7.1* 階層化テクスチャの宣言 4.9.7.2* 他の階層化テクスチャの例 4.9.8* 他のすべてが失敗したら:マテリアルマップ 4.9.9* 特殊テクスチャの制限 4.10 大気の効果を使用する 4.10.1 背景 4.10.2 天球 4.10.2.1 色勾配で空をつくる 4.10.2.2 太陽を加える 4.10.2.3 雲を加える 4.10.3 フォグ(霧) 4.10.3.1 コンスタントフォグ(一定の霧) 4.10.3.2 最小の半透明性をセットする 4.10.3.3 フィルタリングフォグを作る 4.10.3.4 フォグに動乱を加える 4.10.3.5 グランドフォグを使う(地上霧) 4.10.3.6 複数層のフォグを使う 4.10.3.7 中空オブジェクトとフォグ 4.10.4* 大気(Atmosphere) 4.10.4.1 空の部屋から始める 4.10.4.2 部屋にダストを追加する 4.10.4.3 適切なサンプリングレートを選ぶ 4.10.4.4 色のついた大気 4.10.4.5 大気のヒント 4.10.4.5.1 距離と散乱パラメータの選択 4.10.4.5.2 大気と光源 4.10.4.5.3 大気の散乱タイプ 4.10.4.5.4 画像の解像度を増やす 4.10.4.5.5 中空オブジェクトと大気を使う 4.10.5 虹 4.10.5.1 簡単な虹から始める 4.10.5.2 虹の半透明性を増やす 4.10.5.3 虹の弧を使う 4.10.6* アニメーション 4.10.6.1* Clock変数:そのすべての鍵 4.10.6.2* clock依存変数とマルチ・ステージ・アニメーション 4.10.6.3* Phase(位相)キーワード 4.10.6.4* Jitter や Crandを使用するな 4.10.6.5* INI ファイルの設定 5 POV-Ray リファレンス 6 POV-Ray オプション 6.1 POV-Rayオプションをセットする 6.1.1 コマンドラインスイッチ 6.1.2 INI ファイルを使う 6.1.3 POVINI 環境変数を使う 6.2 オプション　リファレンス 6.2.1 アニメーションオプション 6.2.1.1 外部アニメーションループ 6.2.1.2 内部アニメーションループ 6.2.1.3 アニメーションフレームのサブセット 6.2.1.4 サイクリックなアニメーション 6.2.1.5 フィールドレンダリング 6.2.2 出力オプション 6.2.2.1 一般出力オプション 6.2.2.1.1 出力画像の高さと幅 6.2.2.1.2 部分出力オプション 6.2.2.1.3 割り込みオプション 6.2.2.1.4 再開オプション 6.2.2.2 ディスプレイ出力オプション 6.2.2.2.1 ディスプレイのハードウェア設定 6.2.2.2.2 ディスプレイに関連した設定 6.2.2.2.3 モザイク　プレビュー 6.2.2.3 ファイル出力オプション 6.2.2.3.1 出力ファイル形式 6.2.2.3.2 出力ファイル名 6.2.2.3.3 出力ファイルバッファ 6.2.2.4 CPU使用状況ヒストグラム 6.2.2.4.1 ファイル形式 6.2.2.4.2 ファイル名 6.2.2.4.3* 格子のサイズ 6.2.3 シーン構文解析のオプション 6.2.3.1 入力ファイル名 6.2.3.2 ライブラリのパス 6.2.3.3 言語バージョン 6.2.3.4 ユーザ境界の削除 6.2.4 オペレーティングシステムへのシェルアウト 6.2.4.1 シェルコマンドにおける文字列の代入 6.2.4.2 シェルコマンドの順序 6.2.4.3 シェルコマンドのリターンアクション 6.2.5 テキスト出力 6.2.5.1 テキストストリーム 6.2.5.2 コンソールテキスト出力 6.2.5.3 テキスト ストリームをファイルに向ける 6.2.5.4 ヘルプスクリーンの切り替え 6.2.6 トレーシング オプション 6.2.6.1 クオリティの設定 6.2.6.2 ラディオシティーの設定 6.2.6.3 自動境界制御 6.2.6.4 アンチエイリアス オプション 7 シーン記述言語 7.1 言語の基礎 7.1.1 識別子とキーワード 7.1.2 コメント 7.1.3 浮動小数点数(Float)式 7.1.3.1 浮動小数点数リテラル 7.1.3.2 浮動小数点数識別子 7.1.3.3 浮動小数点数演算子 7.1.4 ベクトル計算式 7.1.4.1 ベクトルリテラル 7.1.4.2 ベクトル識別子 7.1.4.3 ベクトル演算子 7.1.4.4 演算子プロモーション 7.1.5 カラーの指定 7.1.5.1 カラーベクトル 7.1.5.2 Colorキーワード 7.1.5.3 カラー識別子 7.1.5.4 カラー演算子 7.1.5.5 よくあるカラーの落とし穴 7.1.6 文字列 7.1.6.1 文字列リテラル 7.1.6.2 文字列識別子 7.1.7 組み込み識別子 7.1.7.1 定数の組み込み識別子 7.1.7.2 組み込み識別子 'clock' 7.1.7.3 組み込み識別子 'version' 7.1.8 関数 7.1.8.1 浮動小数点数 関数 7.1.8.2 ベクトル関数 7.1.8.3 文字列関数 7.2 言語命令 7.2.1 インクルードファイル 7.2.2 宣言 7.2.2.1 識別子の宣言 7.2.3 デフォルト命令 7.2.4 バージョン命令 7.2.5 条件 命令 7.2.5.1 IF ELSE 命令 7.2.5.2 IFDEF 命令 7.2.5.3 IFNDEF 命令 7.2.5.4 SWITCH CASE および RANGE 命令 7.2.5.5 WHILE 命令 7.2.6 ユーザーメッセージ 命令 7.2.6.1 テキストメッセージストリーム 7.2.6.2 テキストフォーマッティング 7.3 POV-Rayの座標系 7.3.1 変換 7.3.1.1 平行移動 7.3.1.2 拡大縮小 7.3.1.3 回転 7.3.1.4 マトリックスキーワード 7.3.2 変換順序 7.3.3 変換識別子 7.3.4 テクスチャーとオブジェクトの変換 7.4 カメラ 7.4.1 投影のタイプ 7.4.2 焦点ぼけ 7.4.3 カメラ光線のぶれ 7.4.4 カメラを置く 7.4.4.1 位置と視線 7.4.4.2 天空ベクトル 7.4.4.3 方向ベクトル 7.4.4.4 角度 7.4.4.5 上方向および右方向ベクトル 7.4.4.5.1 アスペクト比 7.4.4.5.2 利き手 7.4.4.6 カメラの変換 7.4.5 カメラ識別子 7.5 オブジェクト 7.5.1 中空および中実オブジェクト 7.5.1.1 ハロー の落とし穴 7.5.1.2 屈折 落とし穴 7.5.2 有限ソリッドプリミティブ 7.5.2.1 ブロブ 7.5.2.2 ボックス 7.5.2.3 コーン 7.5.2.4 円筒 7.5.2.5 ハイトフィールド 7.5.2.6 ジュリアフラクタル 7.5.2.7 レイズ 7.5.2.8 プリズム 7.5.2.9 球 7.5.2.10 超２次楕円体 7.5.2.11 回転面 7.5.2.12 テキスト 7.5.2.13 トーラス 7.5.3 有限パッチプリミティブ 7.5.3.1 双三次パッチ 7.5.3.2 ディスク(円盤) 7.5.3.3 メッシュ 7.5.3.4 ポリゴン 7.5.3.5 三角形および平滑三角形 7.5.4 無限ソリッドプリミティブ 7.5.4.1 平面 7.5.4.2 多項式、3次および4次関数 7.5.4.3 2次関数 7.5.5 構成的立体幾何 7.5.5.1 CSGについて 7.5.5.2 内側と外側 7.5.5.3 反転(インバース) 7.5.5.4 結合(ユニオン) 7.5.5.5 交差(インターセクション) 7.5.5.6 差(ディファレンス) 7.5.5.7 併合(マージ) 7.5.6 光源 7.5.6.1 点光源 7.5.6.2 スポットライト 7.5.6.3 円筒光源 7.5.6.4 面光源 7.5.6.5 影を作らない光 7.5.6.6 Looks_like(〜のように見える) 7.5.6.7 ライト・フェイディング 7.5.6.8 大気との相互作用 7.5.6.9 大気による減衰 7.5.7 オブジェクト修飾子 7.5.7.1 Clipped_By(切り取られる) 7.5.7.2 Bounded_By(境界付けされる) 7.5.7.3 Hollow(中空) 7.5.7.4 No_Shadow(影無し) 7.5.7.5 Sturm(ステュルム) 7.6 テクスチャ 7.6.1 ピグメント 7.6.1.1 ソリッドカラーピグメント 7.6.1.2 カラーリストピグメント 7.6.1.3 カラーマップ 7.6.1.4 ピグメントマップ 7.6.1.5 イメージマップ 7.6.1.5.1 イメージマップを記述する 7.6.1.5.2 map_type オプション 7.6.1.5.3 Filter および Transmit Bitmap 修飾子 7.6.1.5.4 アルファチャネルを使う 7.6.1.6 クイックカラー 7.6.2 法線(Normal) 7.6.2.1 傾斜マップ 7.6.2.2 法線マップ 7.6.2.3 バンプマップ 7.6.2.3.1 バンプマップを記述する 7.6.2.3.2 Bump_Size(バンプサイズ) 7.6.2.3.3 Use_Index および Use_Color 7.6.3 仕上げ(Finish:フィニッシュ) 7.6.3.1 環境光 7.6.3.2 拡散反射項目 7.6.3.2.1 拡散(Diffuse) 7.6.3.2.2 光輝(Brilliance) 7.6.3.2.3 Crand 粗さ 7.6.3.3 ハイライト 7.6.3.3.1 フォンハイライト 7.6.3.3.2 鏡面ハイライト 7.6.3.3.3 メタリックハイライト修飾子 7.6.3.4 鏡面反射 7.6.3.5 屈折 7.6.3.5.1 光の減衰 7.6.3.5.2* 模造火線 7.6.3.6 虹色の光彩 7.6.4* ハロー 7.6.4.1 ハローマッピング 7.6.4.2 複数のハロー 7.6.4.3 ハローのタイプ 7.6.4.3.1 減衰する(Attenuating) 7.6.4.3.2 ダスト(Dust) 7.6.4.3.3 発光(Emitting) 7.6.4.3.4 白熱(Glowing) 7.6.4.4 密度マッピング 7.6.4.4.1 ボックスマッピング 7.6.4.4.2 円筒状マッピング 7.6.4.4.3 平面マッピング 7.6.4.4.4 球状マッピング 7.6.4.5 密度関数 7.6.4.5.1 定数 7.6.4.5.2 線形 7.6.4.5.3 ３次 7.6.4.5.4 多項式 7.6.4.6 ハローカラーマップ 7.6.4.7 ハローサンプリング 7.6.4.7.1 サンプルの数 7.6.4.7.2 スーパーサンプリング 7.6.4.7.3 ジッタ 7.6.4.8 ハローの修飾子 7.6.4.8.1 Frequency修飾子 7.6.4.8.2 Phase修飾子 7.6.4.8.3 Transformation修飾子 7.6.5 スペシャルテクスチャ 7.6.5.1 テクスチャマップ 7.6.5.2 タイル 7.6.5.3 マテリアルマップ 7.6.5.3.1 マテリアルマップを記述する 7.6.6 多層テクスチャ 7.6.7 パターン 7.6.7.1 めのう(Agate) 7.6.7.2 平均(Average) 7.6.7.3 ボウゾウ(Bozo) 7.6.7.4 煉瓦(Brick) 7.6.7.5 凸凹／バンプ(Bumps) 7.6.7.6 チェッカー(Checker) 7.6.7.7 細かいひび(Crackle) 7.6.7.8 くぼみ(Dents) 7.6.7.9 勾配(Gradient) 7.6.7.10 花崗岩(Granite) 7.6.7.11 六角形(Hexagon) 7.6.7.12 豹(Leopard) 7.6.7.13 マンデル(Mandel) 7.6.7.14 大理石(Marble) 7.6.7.15 タマネギ(Onion) 7.6.7.16 キルト(Quilted) 7.6.7.17 放射(Radial) 7.6.7.18 波紋(Ripples) 7.6.7.19 螺旋1(Spiral1) 7.6.7.20 螺旋2(Spiral2) 7.6.7.21 斑点(Spotted) 7.6.7.22 波(Waves) 7.6.7.23 木(Wood) 7.6.7.24 しわ(Wrinkles) 7.6.8 パターン修飾子 7.6.8.1 パターンを変形させる 7.6.8.2 周波数と位相(Frequency and Phase) 7.6.8.3 波形(Waveform) 7.6.8.4 動乱(Turbulence) 7.6.8.5 オクターブ(Octaves) 7.6.8.6 ラムダ(Lambda) 7.6.8.7 オメガ(Omega) 7.6.8.8 ワープ(Warps:ゆがみ) 7.6.8.8.1 ブラックホールワープ 7.6.8.8.2 繰り返しワープ 7.6.8.8.3 動乱ワープ 7.6.8.9 ビットマップ修飾子 7.6.8.9.1 once オプション 7.6.8.9.2 "map_type" オプション 7.6.8.9.3 interpolate オプション 7.7 大気の効果 7.7.1* 大気 7.7.2 背景 7.7.3 フォグ(霧) 7.7.4 天球 7.7.5 虹 7.8 グローバルな設定 7.8.1 ADC_Bailout(適合深さ制御_からの脱出) 7.8.2 環境光 7.8.3 Assumed_Gamma(仮定されたガンマ) 7.8.3.1 モニタのガンマ値 7.8.3.2 イメージファイルのガンマ値 7.8.3.3 シーンファイルのガンマ値 7.8.4 HF_Gray_16(ハイトフィールド用モノクロ16階調) 7.8.5 Irid_Wavelength(虹色の波長) 7.8.6 Max_Trace_Level(最大トレースレベル) 7.8.7 Max_Intersections(最大交差数) 7.8.8 Number_Of_Waves(波の数) 7.8.9* ラディオシティ 7.8.9.1 ラディオシティの動作 7.8.9.2 ラディオシティの調整 7.8.9.2.1 brightness(輝度) 7.8.9.2.2 count(カウント) 7.8.9.2.3 distance_maximum(距離の最大) 7.8.9.2.4 error_bound(誤差境界) 7.8.9.2.5 gray_threshold(グレイしきい値) 7.8.9.2.6 low_error_factor(低誤差係数) 7.8.9.2.7 minimum_reuse(最少再使用) 7.8.9.2.8 nearest_count(最も近いカウント) 7.8.9.2.9 radiosity_quality(ラディオシティの品質) 7.8.9.2.10 recursion_limit(再帰の限界) 7.8.9.3 ラディオシティに関する助言 *** 付録 *** A 著作権 A.1 全般的なライセンスの取り決め A.2 使用準備 A.3 すべての配布に対する全般的な規則 A.4 「フルパッケージ」の定義 A.5 オンラインサービスとBBSのための配布条件 A.6 POV-Rayのオンラインおよびリモート実行 A.7 カスタム版の配布のための条件 A.8 商用のバンドルのための条件 A.9* 本ソフトウェアの小売値 A.10 他の準備 A.11 ライセンスの取り消し A.12 拒絶 A.13 技術的な援助 B 作者 C 著者と連絡をとる D POV-Rayチームメンバーのためのはがき E* 名誉(Credits) F 助言とヒント F.1 シーンデザインについて助言 F.2 シーンでバックについての助言 F.3 アニメーションについての助言 F.4 テクスチャについての助言 F.5 ハイトフィールドについての助言 F.6 "Handedness"(座標系)を変える G 頻繁に尋ねられた質問(FAQ) G.1 全般的質問 G.2* POV-Rayのオプションに関する質問 G.3* インクルードファイルの質問 G.4* オブジェクトの質問 G.4.1* ハイトフィールドの質問 G.4.2* テキストの質問 G.5 大気に関する質問 G.5.1* 大気の質問 G.5.2* フォグの質問 H 読書の提案 I* ヘルプのためのヘルプ 1 序 本ドキュメントは Persistence of Vision(tm) Ray Tracer (POV-Ray(tm))の使用法を記述するものである。内容は4つの部分に分けられる:インストールガイド、チュートリアルガイド(手引き)、リファレンスガイドと付録である。第1部(「プログラムの記述」 および 「クイックスタート」の章)では、POV-Rayを入手しインストールする方法を述べる。また、レイトレーシングの簡単な紹介も述べる。チュートリアル(「初心者向けの手引き」の章を参照)は、POV-Rayの様々な機能をどのように使うかを一歩一歩説明する。リファレンスは、すべてのコマンドラインオプション(INIファイルキーワード)とシーン記述言語(「POV-Rayリファレンス」、「POV-Rayオプション」と「シーン記述言語」の章を見て下さい。)を説明し、利用できるPOV-Rayの機能のすべての完全な仕様を与える。付録には、いくつかのヒント、お勧めの読み物、コンタクトアドレス、そして、法律上の情報を含む。 1.1 表記法 本ドキュメントではシーン記述言語のキーワード、コマンドラインオプション、INIファイルキーワードおよびファイル名などをマークするために一貫して以下の表記法を用いる。 name シーン記述キーワード name コマンドラインオプション name INI ファイルキーワード name ファイル名 name インターネットアドレス、Usenetのグループ アスキーテキスト版の文書ではそれぞれの表記法の間に差はない。 2 本プログラムについて Persistence of Vision(tm) Ray-Tracerは3次元のフォトリアリスティック(photo-realistic)なイメージをレイトレーシング(Ray-tracing:光線追跡法)と呼ばれるレンダリング(rendering:表現)手法を用いて作成する。それは、シーン(scene)の中のオブジェクトと照明の情報が記述されたテキストファイルを読んで、テキストファイルの中で記述したカメラの位置から眺めたそのシーンのイメージを生成する。レイトレーシングは決して高速な手法ではない。しかし、リアルな反射、陰影付け、透視および他の効果により非常に高品質のイメージを生成する。 2.1 レイトレーシングとは何か? レイトレーシングは光線をシーンに発射することによってそのシーンのイメージを計算するレンダリング手法である。シーンは形状、光源、カメラ、材質、特別な機能(features:フィーチャー)などから構成される。 最終的なイメージの中のすべての画素(pixel:ピクセル)に対して一つないし複数の視線光線(viewing ray)は、シーンの中に発射されて、シーンの中のすべてのオブジェクトとの交差を見つけるため検査される。視線光線はカメラ(camera)で記述される観察者から発し、(最終イメージを描写する)ビューイングウィンドウ(viewing window)を通り抜ける。 視線光線がオブジェクトに当たった場合、常にその点の表面の色が計算される。この目的のために、その表面上の点が影の中にあるかそうでないかを決めるために、シーンの中のすべての光源から届く光の量が決定される。もし表面が反射したり半透明であったりする場合、最終的な表面色への反射および屈折による光の寄与を決定するために、新しい光線がセットアップされ追跡される。 ラディオシティ(radiosity)のような相互拡散(inter-diffuse)反射、大気の効果(atmospheric effect)、エリア(面)光のような特別な機能では、すべてのピクセルについて、たくさんの付加光線をシーンへ発射することが必要となる。 2.2 POV-Rayとは何か? Persistence of Vision(tm) Ray-Tracer はDavid K. Buck と Aaron A. Collinsによって作られたDKBTrace 2.12をもとにPOV-Team(tm)と呼ばれる人々の集団により、彼らの余暇の中で開発された。POV-Team の本部は CompuServeの POVRAYフォーラムにある(詳しくは「CompuServeのPOVRAYフォーラム」を参照 )。 POV-Ray(tm)のパッケージにはレイトレーシングを用いてシーンを作成するための詳細な解説が付属している。多くのすてきなシーンがPOV-Rayに付属しているので、あなたはパッケージを入手したらすぐにイメージ作りを始めることができる。それらのシーンは修正することができるのであなたはゼロから出発する必要はない。 あらかじめ定義されたシーンに加えて、あらかじめ定義された形と材料の大きいライブラリがある。あなたは、形状や材料の名前とそれらの該当するソースファイルの名前を挿入するだけであなたのシーンにこれらの形状や材料を含めることができる。 POV-Rayの機能のハイライトをここに示す: * シーン記述言語の使用が簡単。 * 素晴らしいサンプルシーンファイルの膨大なライブラリ * 形状、色、テクスチャをあらかじめ定義した標準インクルードファイル * きわめて高品質な出力イメージファイル(最大48bitの色数)。 * IBM-PC用の15 および 24 bit カラーディスプレイに該当するハードウェアの使用 * なめらかなハイトフィールド (height fields)を用いたシーンの作成。 * 洗練されたライティングのためのスポットライト、円筒光およびエリア光 * よりリアルな表面のためのPhong および鏡のような(specular)ハイライティング * よりリアルなライティングのための相互拡散反射(radiosity:ラディオシティ) * 大気、霧、虹などのための大気の効果 * 雲、ほこり、炎、蒸気など効果をモデル化するためのハロー(halo) * TGA、PNG および PPMを含む複数の出力ファイルフォーマット。 * 球(spheres)、ボックス(boxes)、二次関数(quadrics)、円筒(cylinders)、三 角錐(cones)、三角形(triangles)および平面(planes)のような基本的プリミテ ィブ。 * トーラス(輪環面)(torii (ドーナッツ))、双曲面(hyperboloids)、放物面 (paraboloids)、ベジェパッチ(bezier patches)、ハイトフィールド( height fields (山脈))、ブロブ (blobs)、4次多項式(quartics)、平滑三角形(smooth triangles:スムーズトライアングル)、 テキスト(text)、フラクタル(fractals)、超2次曲面(superquadrics)、回転面 (surfaces of revolution)、プリズム(prisms)、多角形(polygons)、レイズ (lathes:ろくろ)などの高度なプリミティブ。 * 構成的立体幾何(Constructive Solid Geometry (CSG))により新しい複雑な形状 を簡単に組み合わせて作成。POV-Ray はunions(和、結合、ユニオン)、merges 　　(併合、マージ)、intersections(積、交差) および differences(差)をサポート。 * テクスチャとよばれる質感をオブジェクトに割り当てられる(テクスチャは形状の 色と表面の性質を記述する)。 * 組み込まれた色と法線パターン:めのう(Agate)、ボウゾウ※(Bozo)、凹凸(Bumps)、 チェッカー(Checker)、細かいひび(Crackle)、くぼみ(Dents)、花崗岩(Granite)、 勾配(Gradient)、六角形(Hexagon)、豹(Leopard)、マンデル(Mandel)、大理石 (Marble)、タマネギ(Onion)、キルティング(Quilted)、波紋(Ripples)、まだら (Spotted)、螺旋(Spiral)、放射(Radial)、波(Waves)、木(Wood)、しわ(Wrinkles) およびイメージファイルマッピング。 (※訳注:大きくて強いがまぬけの意?) * ユーザは独自のテクスチャをあらかじめ定義された真鍮(Brass)、クロム(Chrome)、 銅(Copper)、金(Gold)、銀(Silver)、石(Stone)、木(Wood)などのテクスチャから作 成できる。 * テクスチャファイルやマテリアルマップファイルの半透明テクスチャやタイルを重 ねたテクスチャの組み合わせ。 * 計算中にイメージのプレビューを表示 (すべてのプラットホームではない) * 一部分が終了した段階でのレンダリングの中断 * その後中断したレンダリングの再開 2.3 あなたはどのバージョンのPOV-Rayを使うべきか? POV-RayはMS-DOS、Windows 3.x、Windows for Workgroups 3.11、Windows 95、Windows NT、Apple Macintosh 68k、Power PC、Commodore Amiga、Linux、Unix および他のプラットホーム(動作環境)で使用することができる。 必要なファイルの最も新しいバージョンはコンピュサーブ(CompuServe)、インターネット(Internet)、アメリカオンライン(America Online)およびいくつかのBBSで得られる。詳しくは「どこでPOV-Rayのファイルを見つけるか」のセクションを参照されたい。 2.3.1 IBM-PC およびその互換機(DOS/V) 現在IBM-PCのために異なる三つのオペレーティングシステム(MS-DOS、Windows、Linux)の下で動作する以下に述べる3つの異なる版がある。 2.3.1.1 MS-DOS MS-DOSバージョンはMS-DOSあるいはDOSアプリケーションとしてWindows'95、Windows NT、Windows 3.1あるいはWindows for Workgroups 3.11の下で動作する。また、OS/2 およびWarpでも動作する。 必要なハードウェアとソフトウェア: - 386以上のCPUと最小4メガのRAM。 - インストールするために6メガ、作業領域として2-10メガ以上のディスクスペース。 - ASCIIテキストが編集できるテキストエディター。MD-DOSに付属のEDITプログラム でも中規模のファイルまでは扱える。 - グラフィックファイルを見るためのGIFおよびTGA,PNGフォーマット形式に対応した 表示ソフトウェア(viewer)。 必要な POV-Ray ファイル: - POVMSDOS.EXE - 自己展開型アーカイブでプログラム、サンプルシーン、標準イン クルードファイルおよびハイパーテキストヘルプフォーマットのドキュメンテーシ ョンがヘルプビューアーとともに付属する。このファイルはダウンロードの便宜の ため小さなファイルに分割されているかも知れない。あなたのダウンロードディレ クトリあるいはFTPサイトを見て、他に必要なファイルがないか確認してください。 推奨されるもの: - Pentium あるいは 486dx あるいは 386,486sx用数値計算コプロセッサ。 - 8 メガ以上のRAM。 - VESAインターフェースのSVGAディスプレイでハイカラーあるいはトゥルーカラーの 能力 オプション: POV-Rayを使うにはソースコードは不要であるが、好奇心と冒険心の強い人のために与えられる。 - POVMSD_S.ZIP - C 言語によるPOV-Ray for MS-DOSのソースコード。共通部分とMS- DOS用の部分からなる。サンプルシーン、標準インクルードファイル、およびドキ ュメンテーションは含まない。従って実行形式のアーカイブも必要である。 - 32-bitプロテクトモードアプリケーションを作成できるCコンパイラ。われわれは Watcom 10.5a、DOSパワーパック付きのBorland 4.5、制限付きのDJGPP 1.12maint4 のグラフィックスをサポートする。DJGPP 2.0はサポートされない。 2.3.1.2 Windows Windows版はWindows'95、Windows NT およびWin32sを拡張したWindows 3.1あるいは 3.11で動作する。OS/2 Warpでも動作する。 必要なハードウェアとソフトウェア: - 386以上のCPU、および少なくとも8メガのRAM。 - インストールに12メガ、作業スペースにさらに2-10メガのディスクスペース。 必要な POV-Ray ファイル: - ユーザ用アーカイブ POVWIN3.EXE - 自己展開アーカイブでプログラム、サンプ ルシーン、標準インクルードファイルおよびドキュメンテーションを含む。このフ ァイルはダウンロードの便宜のため小さなファイルに分割されているかも知れませ ん。あなたのダウンロードディレクトリあるいはFTPサイトを見て他に必要なファ イルがないか確認してください。 推奨されるもの: - Pentium あるいは 486dx あるいは386 および 486sx用の数値演算コプロセッサ。 - 16 メガ以上の RAM。 - SVGA ディスプレーでハイカラーあるいはトゥルーカラー能力のあるものでドライ バがインストールされていること。 オプション: POV-Rayを使うにはソースコードは不要であるが、好奇心と冒険心の強い人のために与えられる。 - POVWIN_S.ZIP --- C 言語によるPOV-Ray for Windowsのソースコード。共通部分と Windows用の部分からなる。サンプルシーン、標準インクルードファイル、および ドキュメンテーションは含まない。従って実行形式のアーカイブも必要である。※ - POV-Ray は32-bit Windowsアプリケーションを作成可能なコンパイラでのみコンパ イルできる。われわれは Watcom 10.5a、Borland 4.52/5.0 コンパイラをサポー トする。 (※訳注:翻訳時'97/2にはINTERNETではまだ公開されていない。CompuServeでは公開されているらしい) 2.3.1.3 Linux 必要なハードウェアとソフトウェア: - 386以上のCPUおよび少なくとも4メガのRAM。 - インストールに6メガ、作業スペースにさらに2-10メガのディスクスペース。 - ASCIIテキストファイルが編集できるテキストエディタ。 - 最近の(1994 以降) Linux カーネル、および ELFフォーマットバイナリのサポート POV-Ray for Linuxはa.outフォーマットではない。※ - ELF ライブラリ libc.so.5、libm.so.5 および libX11.so.6とlibvga.so.1のどち らか一方あるいは両方。 (※訳注:ソースを入手し再コンパイルすれば良い) 必要なPOV-Ray ファイル: - POVLINUX.TGZ あるいは POVLINUX.TAR.GZ - アーカイブ。含んでいるのは各 SVGALib および X-Windows モードのための正式バイナリー。また、サンプルシーン、標準 インクルードファイルおよびドキュメンテーションも含む。 推奨: - Pentium あるいは 486dx あるいは386および 486sx用数値演算コプロセッサ。 - 8 メガ以上のRAM。 - SVGA ディスプレイでハイカラーあるいはトゥルーカラーの機能のある物。 - もし表示したいのならばSVGALib あるいは X-Windowsのどちらかが必要。 - PPM、TGA あるいは PNGフォーマットの表示が可能なグラフィックファイルビュー アー オプション: POV-Rayを使うにはソースコードは不要であるが、好奇心と冒険心の強い人のために与えられる。 - POVUNI_S.TAR.GZ あるいは POVUNI_S.TGZ - POV-Ray for LinuxのCソースコード。 共通部分とLinux用の部分からなる。サンプルシーン、標準インクルードファイル、 およびドキュメンテーションは含まない。従って実行形式のアーカイブも必要であ る。 - GNU C コンパイラおよび (オプションで) X インクルードファイルとライブラリお よびそれをどう使うかの知識。我々は一般的なUnixシステムのためにソースコード を提供するけれども、プログラムをコンパイルする方法についての技術的な援助は 提供しない。 2.3.2 Apple Macintosh(アップル　マッキントッシュ) マッキントッシュ版はアップル社の68020/030/040-ベースの Macintosh (数値演算プロセッサの有無によらず)あるいはパワーマックでオペレーティングシステムが MacOS version 7.0かそれ以上のもとで動作する。 必要なハードおよびソフトウェア: - 68020以上の CPU で浮動小数点ユニットのないもの (LC か Performa か Centris シリーズ) で8メガ以上のRAM あるいは - 68020以上の CPU で浮動小数点ユニット付きのもの (Mac II か Quadra シリーズ) で8メガ以上のRAM あるいは - すべてのパワーマッキントッシュで8メガ以上のRAM - System 7 以降でカラー QuickDraw (System 6 はもうサポートしない)。 - インストールのために約6メガの空きディスクスペースと作業領域のためにさらに 2-10メガの空きディスクスペース。 - Mac PICT、GIFおよびたぶんTGA と PNG画像ファイルを表示可能なユーティリティ プログラム(シェアウェアの GIFConverter か GraphicConverter がいいでしょう) 必要な POV-Ray ファイル: - POVMACNF.SIT あるいは POVMACNF.SIT.HQX - StuffitのアーカイブでFPU無しの 68K Macintosh のアプリケーション、サンプルシーン、標準インクルードファイル およびドキュメンテーションを含む(FPU無しの遅いMacs用) あるいは - POVMAC68.SIT あるいは POVMAC68.SIT.HQX - StuffitのアーカイブでFPU付きの 68K Macintosh のアプリケーション、サンプルシーン、標準インクルードファイル およびドキュメンテーションを含む(FPU付きの速いMacs用) あるいは - POVPMAC.SIT or POVPMAC.SIT.HQX - StuffitのアーカイブでネイティブなPower Macintoshアプリケーション、サンプルシーン、標準インクルードファイルおよび ドキュメンテーションを含む(Power Macintosh用)。 推奨: - 68030/33 かより速いFPU付きの機種、あるいはPower Macintosh - 8メガ以上のRAM の 68K Macintosh; 16メガ以上のPower Macintosh システム。 - カラーモニターが望ましい、256色ならOK。でも数千あるいは数百万色ならなお 　　良い。 オプショナル: POV-Rayを使うのにソースコードは必要ないが、好奇心の強い冒険好きな者のために与えられている。POV-Ray はApple's MPW 3.3、Metrowerks CodeWarrior 8 か Symantec 8 でコンパイル可能である。 - POVMACS.SIT か POVMACS.SIT.HQX - C 言語によるPOV-Ray for Macintoshの全ソ ースコード。共通部分とMacintosh用の部分からなる。サンプルシーン、標準イン クルードファイル、およびドキュメンテーションは含まない。従って実行形式のア ーカイブも必要である。 2.3.3 Commodore Amiga(コモドールアミガ) Amiga版はいくつかのフレーバー用にある: 68000/68020 FPU無し(推奨しない、非常に遅い)、68020/68881(68882)、68030/68882 および 68040。 さらに2つのサブバージョンがある。一つは CLI※-だけのインターフェースのもので、もう一つはGUIのものである(MUI 3.1が必要)。いずれのバージョンともOS2.1以上で動作する。256色パレットとCybeGFXディスプレイライブラリをサポートするOS3.x上の pensharingとウインドウディスプレイのためのサポートは存在する。 (※訳注:コマンドラインインターフェース) 要求されるもの: - 少なくとも4メガの RAM。 - 少なくとも2メガのハードディスクスペースが必要で、さらにワークスペースに 5- 20メガが推奨される。 - ASCII テキストエディタ、あなたの選択するエディタを起動するために可変 (configurable)なGUI。 - グラフィックファイルビューアー - POV-RayはPNG、Targa (TGA)および PPMフォ ーマットを出力する。これらをIFF ILBMファイルにコンバートするためのPPMBINデ ィストリビューションからのコンバーターが含まれている。 必要な POV-Ray ファイル: - POVAMI.LHA - 実行形式、サンプルシーン、標準インクルードファイルとドキュメ ンテーションを含むLHA アーカイブ。 推奨されるもの: - 8メガ以上の RAM。 - 68030 および 68882 あるいはそれ以上のプロセッサ。 - 24bit ディスプレイカード(CyberGFXライブラリがサポートされるもの) Amiga PowerPC用の安定なコンパイラがリリースされ次第、フレーバーリストにこれを加えるプランがある。 オプション:ソースコードはPOV-Rayを使うのには必要ではないが、好奇心の強い冒険好きな者のために与えられている。 - POVLHA_S.ZIP - Amiga用のPOV-RayのC ソースコード。共通部分とAmiga用の部分 を含む。サンプルシーンと標準インクルードファイルおよびドキュメンテーション は含まれない。したがって実行用のアーカイブも入手しなければならない。 2.3.4 SunOS 必要なハードウェアおよびソフトウェア: - Sun SPARC プロセッサで少なくとも4 meg の RAM。 - インストールのために約 6 megの空きディスクと作業領域によりさらに2-10 meg以 上。 - ASCIIテキストファイルの編集が可能なテキストエディタ。 - SunOS 4.1.3 あるいはそのようなバイナリーを実行可能な他のオペレーティングシ ステム(Solaris か、たぶんSPARC用のLinux)。 必要なPOV-Rayファイル: - POVSUNOS.TGZ か POVSUNOS.TAR.GZ -いずれもテキストオンリーのモードとX- Windowsモードの公式なバイナリを含む。また、サンプルシーン、標準インクルー ドファイルおよびドキュメンテーションも含まれる。 推奨: - 8 meg 以上のRAM。 - もし表示をしたいのならX-Windowsか X-Termが必要であろう。 - Xディスプレーコードはビジュアルとカラーデプスの任意の組み合わせの下で動作 することが知られているが、24-bitのTrueColorディスプレイ能力が好ましい。 - PPM、TGA あるいは PNG フォーマットの表示が可能なグラフィックビューアー。 オプション:ソースコードはPOV-Rayを使うのには必要ではないが、好奇心の強い冒険好きな者のために与えられている。 - POVUNI_S.TGZ か POVUNI_S.TAR.GZ - POV-Ray for UnixのC ソースコード。 共通のUnix部分とLinux用の部分を含む。サンプルシーンと標準インクルードファ イルおよびドキュメンテーションは含まない。したがって実行用のアーカイブも入 手しなければならない。 - C コンパイラおよび (オプションで) Xインクルードファイルおよびライブラリ、 それにそれをどのように使うかの知識。 我々は一般的なUnixシステムのためのソースコードを与えるけれども、どのようにプログラムをコンパイルするかの技術的なサポートは与えない。 2.3.5 一般のUnix(Generic Unix) 必要: - POVUNI_S.TGZ あるいは POVUNI_S.TAR.GZ - POV-Ray for UnixのCソースコード。 それぞれのアーカイブにはすべての共通ソースコードと、Unix と X-Windows 用の 　　ソースが含まれる。 - POVUNI_D.TGZ あるいは POVUNI_D.TAR.GZ あるいはsample scenes、standard 　　include files および documentationを含む他のアーカイブ。これは上に述べた 　　LinuxあるいはSunOS の実行可能なアーカイブでも良いかもしれない。 - あなたのコンピュータ用のCコンパイラおよびそれを使うための知識。 　　われわれは一般のUnixシステム用のソースコードを提供するがプログラムをどう 　　コンパイルするかの技術サポートは提供しない。 - アスキーテキストファイルを編集するためのテキストエディタ。 推賞: - 数値コプロセッサ。 - 8 meg 以上のRAM。 - PPM、TGA あるいは PNG フォーマット用のグラフィックファイルビューアー。 オプション: - X Windows レンダリングしながら表示したいのであれば。 - X-Windows のインクルードファイルも必要。もしあなたがX-Windows用のプログラ ムに通じていないのならば、あなたのインストール状態に詳しい誰かの手助けが必 要であろう。なぜなら Xのインクルードファイルとライブラリが常に標準の場所に あるとは限らないからである。 2.3.6 すべての版について それぞれの実行可能なアーカイブはPOV-Rayの完全なドキュメントとあなたのプラットホームで使うための特定の指示を含んでいる すべての版のプログラムは、同じ形、照明およびテクスチャのようなレイトレーシング機能を共有する。言い換えると、十分なメモリがあれば、IBM-PCがクレイスーパーコンピュータと同じ絵をつくることができる。 ユーザは自分のコンピュータハードウェアに最もマッチする実行可能プログラムを入手したいだろう。セクション「POV-Rayのファイルはどこで見つかるか」を見ればそれらのファイルが見つかる。あなたとあなたのコンピュータに最適の版を見つけるために、これらの情報源にコンタクトをとることができる。 2.3.7 POV-Rayのコンパイル 以下のセクションはあなたが移植可能なCソースコードを動作可能な実行形式のPOV-Rayにコンパイルするための手助けとなるだろう。これらはPOV-Rayのカスタムバージョンの欲しい人やサポートされないプラットホームやコンパイラに移植したい人のためだけの物である。 あなたが自分自身に問わなければならない最初の質問は「私は本当にPOV-Rayをコンパイルすることが必要か」である。正式な POV-Rayチームの実行形式のバージョンはMS-DOS、Windows 3.1x/95/NT、Mac 68k、Mac Power PC、Amiga、Linux for Intel x86、および SunOS版がある。他のプラットホームのための非公式なコンパイルもすぐに利用できるようになる。あなたが独自の機能や実験的機能をプログラムに加えるつもりでないなら、また既にあなたのプラットホーム用の実行形式が存在するならば、あなたは自分でコンパイルする必要はない。 もし、あなたがどうしても先に進みたいならば、最も頼りになるのはあなた自身であるということを認識しなければならない。以下のセクションと他の関連するドキュメントではあなたが自分が何をしているのか知っているものとする。あなたはインストールされ動作する適当なＣコンパイラを持っているものと仮定する。あなたは大きなマルチパートプログラムをメイク(make)ユーティリティや，もしあなたのコンパイラがサポートしていれば、IDE(統合環境)プロジェクトファイルを用いてコンパイルとリンクをする方法を知っているものとする。メイクファイルやプロジェクトファイルはしばしばドライブ、ディレクトリをあるいはパス情報を指定するので、われわれのメイクファイルやプロジェクトファイルがあなたのシステム上でうまく動作するか約束できない。我々は、あなたがあなたのシステムライブラリと他の必要なファイルの位置を指定するためにどのようにメイクファイルとプロジェクトファイルを変更すればよいか知っていると仮定する。 一般に、あなたがどのようにプログラムをコンパイルしたらいいのか、POV-Rayチームからの技術的援助をあてにするべきではない。ここで与えられるものがすべてである。我々が確信して言うことができるのは、我々が我々のシステムの上でそれをコンパイルすることができた、ということだけである。それがあなたのためにうまくいかないとしても、多分我々はあなたに理由を教えられないだろう。 ソースコード自体のドキュメントはソースファイルの中のコメントだけである。我々は良くコメントされた分かりやすいコードのためにベストを尽くしたが、いくつかのセクションはごくわずかのコメントしかなく、いくつかのコメントは内容が古いこともある。我々は、あなたが機能を加えるための技術的な援助を与えない。我々は、特定の機能がどのようにうまくいくかの説明もしない。プログラムのある部分を書いた人はチームの中でもはや現役でない場合もある。そして、我々はそれがどのようにうまくいくのか正確には知らないのである。 POV-Rayのカスタム版、あるいは非公式コンパイルを作る場合、あなたは「著作権」を読んで、我々のライセンスのすべての条項に従うことを確認してほしい。一般にあなたはあなた自身のためにPOV-Rayを修正し、使うことができる、しかし、あなたがあなたの非公式版を配布するのならば、あなたは我々の規則に従わなければならない。あなたは、どんな状況下においても他のプログラムの中でPOV-Rayのソースコードの一部分を使ってはならない。 2.3.7.1 ディレクトリ構造 POV-Rayのソースコードは、ディレクトリかフォルダーの特定の階層に配置されたファイルのアーカイブ(archive)として配布される。アーカイブを展開するときは、完全なディレクトリ構造を保つ方法でするべきである。一般に、我々はあなたがpovray3と名付けられたディレクトリを作って、そこからファイルを展開するように提案する。展開により、多くのファイルとサブディレクトリを持つsourceと名づけられるディレクトリが作成されるだろう。 一般に、それぞれのハードウェアとプラットホームのために別々のアーカイブがあるが、それぞれのアーカイブは複数のコンパイラをサポートする。例えば、MS-DOSアーカイブのためのディレクトリ構造がここにある。 SOURCE SOURCE\LIBPNG SOURCE\ZLIB SOURCE\MSDOS SOURCE\MSDOS\PMODE SOURCE\MSDOS\BORLAND SOURCE\MSDOS\DJGPP SOURCE\MSDOS\WATCOM sourceディレクトリには、すべてのプラットホームに共通なPOV-Rayの一般的な部分のためのソースファイルが入る。source\libpngには、PNG(ポータブルネットワークグラフィックス)イメージファイルを読み書きする際に使われるルーチンのライブラリをコンパイルするためのファイルが入る。source\zlibには、LIBPNGによって使われるデータストリームの圧縮および展開ルーチンのライブラリをコンパイルするためのファイルが入る。これらのファイルのすべては、すべてのプラットホームとコンパイラによって使われる。それらは、ソースアーカイブのあらゆる版に含まれる。 source\msdosディレクトリはMS-DOSをサポートするすべてのコンパイラに共通のMS-DOSバージョンのソースファイルを含む。pmodeサブディレクトリにはすべてのMS-DOS版に必要なpmode.libのためのソースファイルが含まれている。Borland、DJGPP、および Watcom サブディレクトリにはBorland、DJGPP および WatcomのＣコンパイラのためのソース、メイクファイルおよびプロジェクトファイルが含まれる。 source\msdosディレクトリはMS-DOS用のアーカイブだけに含まれる。同様にWindowsアーカイブにはsource\windowsディレクトリがUnixアーカイブにはsource/unixディレクトリが含まれる。 source\msdosにはファイルcmpl_msd.docが含まれる。そこにはMS-DOSバージョンのためのコンパイル情報がある。他のプラットホームの特定のディレクトリにも同様にcmpl_xxx.docファイルがあり、特定のコンパイラのためのサブディレクトリにもcmpl_xxx.docファイルがある。あなたのプラットホームとコンパイラのための適切なcmpl_xxx.docファイルを必ず読んでいただきたい。 2.3.7.2 POV-Rayのソースを構成する すべてのプラットホームに対してファイルconfig.hがある。これは一般にプラットホーム特定のディレクトリにあるが、コンパイラ特定のディレクトリにあるかもしれない。いくつかのプラットホームでは複数のバージョンのこのファイルがあり、あなたはconfig.hにリネームしたりコピーしたりする必要があるかも知れない。このファイルは、POV-Rayのあらゆるモジュールにインクルードされる。そこにはPOV-Rayの一般的な部分に必要とされるプロトタイプ、マクロ、その他の定義が入るが、特定のプラットホームあるいはコンパイラのためにカスタマイズしなければならない。 例えば、異なるオペレーティングシステムでは、ディレクトリとファイル名の間のセパレーターに異なるキャラクタを使う。MS-DOSはバックスラッシュを使い、Unixではフロントスラッシュ、あるいは、Macではコロンである。MS-DOSとwindowsのためのconfig.hファイルには、以下の行が入る: #define FILENAME_SEPARATOR '\\' これはバックスラッシュを使うようにPOV-Rayの一般的な部分に伝える。 コードの一般的な部分が必要とするあらゆるカスタム化に対して、ファイルsource\frame.h中のデフォルト値がある。これもconfig.hの後ですべてのモジュールにインクルードされる。frame.hヘッダには、以下のような多くの定義のグループが入る: #ifndef FILENAME_SEPARATOR #define FILENAME_SEPARATOR '/' #endif これはもしconfig.hの中でこれ以前に定義がされていなければ、これがデフォルト値になることを意味している。あなたがコンフィギュレーションしたいかもしれない、どんな他の値があるかframe.hを見てください。 プラットホーム特定の関数を記述するための定義を行う場合、あなたはその関数のためにプロトタイプも含ませるべきである。例えば、ファイルsource\msdos\config.hにはグラフィックスディスプレイの初期化関数の名前を定義するために以下のマクロが入るだけではない: #define POV_DISPLAY_INIT(w,h) MSDOS_Display_Init ((w), (h)); それにはプロトタイプが入る: void MSDOS_Display_Init (int w, int h); あなたがサポートされていないプラットホームにPOV-Rayを移植するつもりならば、多分、あなたは最も単純なものから出発するべきだろう。それは表示をしない一般的なUnix版である。それからconfig.hファイルを通して新しいカスタム部分を加えるべきである。 2.3.7.3 まとめ 我々は上記のセクションは最も取るに足らないほんの最初のステップであると理解している。しかし、POV-Rayのソースで作業をする楽しみの半分は、あなた自身で探求して、あなた自身のものとしてそれを形作ることである。これがPOV-Rayチームのメンバーが、どのように出発したかである。われわれはできるだけクリアなコードを作ろうとした。 あなたがサポートされたプラットホームかコンパイラの上で作業をしているのなら、細かいヘルプのためにあなたのプラットホームとコンパイラ特定のディレクトリのcmpl_xxx.docファイルを必ず読んで下さい。 2.4 POV-Rayのファイルはどこにあるか POV-Rayソフトウェアの最新版は以下の入手先から得ることができる。 2.4.1 CompuServeのPOVRAYフォーラム POV-Rayの本部は、CompuServeのPOVRAYフォーラムにある。そこはチームのメンバーの誰かが管理している。我々は、そこに参加し、情報とグラフィックスを共有し、レイトレーシングやフラクタルと他の種類のコンピュータ技術を論議する。誰でもCISのPOVRAY上での行動に参加できる。そこでお会いしたい。CompuServeに参加するための情報は(800)848-8990に電話するかCompuServeのホームページ http://www.compuserve.comを訪れると得られる。日本、ヨーロッパおよび多くの他の国から直接CompuServeにアクセス可能である。 2.4.2 インターネット POV-Rayのインターネットホームページは World Wide Webのアドレス http://www.povray.orgとFTPのftp.povray.orgにある。どうか最新のファイル、ユーティリティ、ニュース、イメージのために、このPOV-Rayの公式サイトたびたびアクセスしてほしい。 comp.graphics.rendering.raytracingニュースグループは、知識を共有することにとても自発的で有能な多くのPOV-Rayユーザをもっている。彼らは、一般に、あなたが誰かがすでに同じ質問に答えたかどうか見るために最初に2、3のファイルに目を通すことを求める。もちろんあなたが適当な「ネチケット」に従うことも。あなたがそのグループにいつも集まる人々に疑問を持つならば、www.povray.orgのレイレーシング競争のページを訪ねるためにわずかの時間を費やしてもらえば、あなたを短時間で説得できるだろう。 2.4.3 America On-LineのPC Graphics Area 現在、アメリカオンライン(America On-Line)にPOV-Rayのサーポートと情報のために与えられたセクションがある。あなたは、AOLのPCグラフィックスセクションで、それを見つけることができる。キーワードPOVでジャンプして下さい(キーワードPCGRAPHICSはグラフィックス関係のセクションのトップに移動する)。このセクションには、アップルマッキントッシュの実行形式もある。企業のサポートセクションにメッセージが残せれば最高なんだが。現在、Bill Pulver(BPulver)は、そこでの我々の代表者である。 2.4.4 El Cerrito, CA の The Graphics Alternative BBS 西海岸では、あなたはPOV-RayのファイルをGraphics Alternative BBSで見つけたいかも知れない。それは、Adam Shiffmanによって運営されている大きいグラフィックスBBSである。このTGAは高品質で、活発で進歩的なBBSシステムであり、その1300以上のユーザーに上質の通信とファイルを提供している。 510-524-2780 (PM14400FXSA v.32bis 14.4k、一般) 510-524-2165 (USR DS v.32bis/HST 14.4k、加入者) 2.4.5 PCGNet Professional CAD and Graphics Network (PCGnet) は広く有用な情報を利用できるように、CADとグラフィックスのコミュニティーを提供する。 以前はADEnetとして知られていたが、PCGnet は新たに最初から作られた新しいネットワークである。新しいノードを取り入れCADとグラフィックスに関するトピックスの両方を均一に焦点として以下のトピックスを含んでいるがこれらに限られているわけではない:デザイン、製図、エンジニアリング、2dと3dモデリング、マルチメディア、システム、ラスター画像、レイトレーシング、3dレンダリングとアニメーション。 PCGnetは、先に触れたCADとグラフィックスに関するトピックスに関心を持つ活発なユーザのためにその関心を刺激し、サポートフォーラムを作成することによって、全ての呼び出し人のニーズにかなうようにデザインされている；インタレストとサポートはPCGnetのメッセージ会議、ネットワークを横切るファイル共有、工業ニュースと記者発表を通して作成されている。PCGnetのメッセージ会議は司会者付きの(moderated)フォーラムでCADとグラフィックスに関するフレンドリーでも専門的で有益な議論になるようにデザインされている。 TGA BBSは、世界中のグラフィックス指向のBBSシステムの大きいネットワークのための、中心的ハブの役目を果たす。以下はこれを書いている時点でのアクティブなBCGNetのノードの簡潔なリストである。POVチームはこの情報の通用を保証することはできないし、これらのボードがすべてPOV-Rayを携えているかどうかも確かめることができない。 USA および カナダ 411-Exchange Alpharetta GA 404-345-0008 Autodesk Global Village San Rafael CA 415-507-5921 CAD/Engineering Services Hendersonville TN 615-822-2539 Canis Major Nashville TN 615-385-4268 CEAO BBS Columbus OH 614-481-3194 CHAOS BBS Columbia MO 314-874-2930 Joes CODE BBS West Bloomfield MI 810-855-0894 John's Graphics Brooklyn Park MN 612-425-4436 PC-AUG Phoenix AZ 602-952-0638 SAUG BBS Bellevue WA 206-644-7115 Space Command BBS Kennewick WA 509-735-4894 The CAD/fx BBS Mesa AZ 602-835-0274 The Drawing Board BBS Anchorage AK 907-349-5412 The Graphics Alternative El Cerrito CA 510-524-2780 The Happy Canyon Denver CO 303-759-3598 The New Graphics BBS Piscataway NJ 908-271-8878 The University Shrewsbury Twp NJ 908-544-8193 The Virtual Dimension Oceanside CA 619-722-0746 Time-Out BBS Sadsburyville PA 610-857-2648 オーストラリア MULTI-CAD Magazine BBS Toowong QLD 61-7-878-2940 My Computer Company Erskineville NSW 61-2-557-1489 Sydney PCUG Compaq BBS Caringbah NSW 61-2-540-1842 The Baud Room Melbourne VIC 61-3-481-8720 オーストリア Austrian AutoCAD User Group Graz 43-316-574-426 ベルギー Lucas Visions BBS Boom 32-3-8447-229 デンマーク Horreby SuperBBS Nykoebing Falster 45-53-84-7074 フィンランド DH-Online Jari Hiltunen 358-0-40562248 Triplex BBS Helsinki 358-0-5062277 フランス CAD Connection Montesson 33-1-39529854 Zyllius BBS! Saint Paul 33-93320505 ドイツ Ray BBS Munich Munich 49-89-984723 Tower of Magic Gelsenkirchen 49-209-780670 オランダ BBS Bennekom: Fractal Board Bennekom 31-318-415331 CAD-BBS Nieuwegein 31-30-6090287 31-30-6056353 Foundation One Baarn 31-35-5422143 ニュージーランド The Graphics Connection Wellington 64-4-566-8450 The Graphics Connection II New Plymouth 64-6-757-8092 The Graphics Connection III Auckland 64-9-309-2237 スロベニア MicroArt Koper 386-66-34986 スウェーデン Autodesk On-line Gothenburg 46-31-401718 連合王国(英国) CADenza BBS Leicester, UK 44-116-259-6725 Raytech BBS Tain, Scotland 44-1862-83-2020 The Missing Link Surrey, England 44-181-641-8593 国際電話あるいは長距離電話のダイヤル番号は、付加番号が必要な場合がある。あなたの地区の電話会社に意見を聞いてください。 2.4.6 POV-Ray に関する書籍およびCD-ROM 以下の品目は、POV-チームのメンバーによって作成された。POV-Ray 2.2までに対応しているだけであるが、まだ役に立つだろう。1996年10月頃に予想される新しい版でPOV-Ray CD-ROMを3.0版までアップデートするためのステップがとられている。 以下の書籍は絶版になっているが、どこかの書店や図書館で見つかるかも知れない(詳しくはhttp://www.dnai.com:80/waite/ を訪ねてほしい)。 Ray Tracing Creations, 2d Ed. Chris Young and Drew Wells ISBN 1-878739-69-7 Waite Group Press 1994 カラーページが挿入された700ページでPOV-Ray 2.2の3.5" MS-DOSディスクが付属 する。 Ray Tracing Worlds with POV-Ray Alexander Enzmann, Lutz Kretzschmar, Chris Young, ISBN 1-878739-64-6 Waite Group Press 1994 Moray 1.5x モデラーとPOV-Ray 2.2の3.5" MS-DOSディスクが付属する。 Ray Tracing for the Macintosh CD Eduard Schwan ISBN 1-878739-72-7 Waite Group Press, 1994 シーン、イメージ、およびQuickTimeムービーで満たされたCD-ROMが付属する。 さらに、対話型キーワードリファレンスも付属する。CD ROMドライブを持たない人 のためのPOV-Rayのフロッピーも付属する。 'The Official POV-Ray CDROM'公式の POV-Ray CD-ROM:公式のPOV-Ray CD-ROMは、イメージ、シーンソース、プログラムソース、ユーティリティとインターネットとCompuserveからのPOV-Rayと3Dグラフィックスに関する情報の編集物である。このCDは自分で自身のイメージを作成したり全般的な3Dプログラミングの仕事をしたい人だけでなく、単にPOV-Rayのアーティストにより作成された高品質のレンダリングを体験し、そのソースコードから学びたいたい人をも対象とする。CD-ROMには、500以上のレイトレースされたイメージが入っている。 それは、すでに熟達している人たちと同様にPOV-Rayを学んでいる人たちのためのよい資源であって、マイクロソフトwindowsベースの対話的なチュートリアルが入っている。ディスクは、折りたたみポスターとリファレンスシートとともに来る。CDは、DOS/windowsとマッキントッシュのフォーマットと互換性を持つ。 CD-ROMは、World Wide Web上でhttp://www.povray.org/pov-cdromで無料で検索し、目を通すことができる。さらに詳しくはhttp://www.povray.org/povcdを見てほしい。 3 クイックスタート 　次のセクションは、POV-Rayをインストールして、あなたのコンピュータ上でサンプルシーンをすぐにレンダリングする方法を説明する。ここではあなたがIBM-PCと互換性を持つコンピュータでMS-DOSを使っていると仮定する。他のプラットホームのためには、POV-Rayのアーカイブに含まれる特定のドキュメンテーションを参照しなければならない。 3.1 POV-Rayのインストール 特定のインストールの説明は、あなたのコンピュータ用の実行可能プログラムに含まれる。一般に、POV-Rayをインストールするために2つの手段がある。 [ 注:一般的な語としてディレクトリ(directory)を使う。あなたのオペレーティングシステムでは別の言葉、サブディレクトリ(subdirectory)、フォルダー(folder)、などが使われているかもしれない] 1) きたない(messy)手段: POVRAYと名付けられたディレクトリを作成し、それにすべてのPOV-Rayファイルをコピーしなさい。このディレクトリからすべてのファイルを編集し、プログラムを走らせなさい。この方法は、動くが推奨されない。 あるいは好ましい手段: 2) POVRAYと名付けられたディレクトリを作成し、さらにいくつかのサブディレクトリINCLUDE、DEMO、SCENES、UTILを作ってください。本プログラムのいくつかのバージョンで用いられる自己展開アーカイブはあなたのためにサブディレクトリを作成してくれるでしょう。あなた自身でサブディレクトリを作るのであればファイルツリーは以下のようにしなければなりません。 \- | +POVRAY - | +INCLUDE | +DEMO | +SCENES | +UTIL 実行可能ファイルとドキュメント類をディレクトリPOVRAYにコピーしましょう。標準インクルードファイルをサブディレクトリINCLUDEにコピーしてください。サンプルシーンファイルをサブディレクトリSCENESに、すべての POV-Rayに関係するユーティリティプログラムとそれに関連するファイルをサブディレクトリ UTILにコピーしてください。あなた自身のシーンファイルはSCENESサブディレクトリに入るでしょう。また、ディレクトリ \POVRAY と \POVRAY\UTIL をサーチパスに加える必要があるでしょう。そうすると実行プログラムはどのディレクトリからでも実行できます。 注意:いくつかのオペレーティングシステムにはこのマルチパスサーチコマンドに相当するものがありません。 　第2の方法は、セットアップは少しだけ難しいけれど好ましい方法です。POV-Rayに関連するファイルはたくさんあるので、いくつかのディレクトリに分けておく方が扱いがはるかに簡単になるからです。 3.2 基本的な使用法 注意:あなたがinstall.exeシステムを使ってプログラムをインストールしなかったならば、ここで示される例や指示はうまくいかないかもしれません!インストールプロセスは、povray.iniといくつかの重要なバッチファイルを調整します。これらの調整されたファイルなしでは、例はうまく動作しないかもしれません。 POV-Rayの基本的な目的は、POV言語で書かれたシーン記述を読み込み、イメージファイルを書き出すことである。シーンファイルは、あなたがテキストエディタを使ってつくるアスキーテキストファイルである。何十ものサンプルファイルが、様々な機能を図示するためにこのパッケージに含まれています。 あなたは、MS-DOSプロンプトでコマンドをタイプすることによってPOV-Rayを呼び出します。コマンドは、POVRAYとそれに続く一つ以上のコマンドラインスイッチからなります。各スイッチは、プラスあるいはマイナスの符号から始まり、空白はスイッチを区切ります。スイッチは大文字でも良いし小文字でもよろしい。 注:このドキュメンテーションの中の例では、あなたがc:\povray3ディレクトリの中にPOV-Rayをインストールしたと仮定します。インストーラーはPOV-Rayをどこにでもインストール可能で、あなたが指定したドライブとディレクトリで正しく構成します。あなたは、我々がc:\povray3を使うと記述するすべてを、ただそのドライブとディレクトリに代えればよろしい。今、そのディレクトリに移動してください。そしたら以下のコマンドラインをタイプし[ENTER]を押しなさい。 POVRAY +ISHAPES +D1 +I コマンド( input )は入力として読み込むファイルが何かをプログラムに伝える。ファイル名に拡張子を付けない場合は.povが仮定される。したがって +I shapesはレンダリングするために読み込むファイルが shapes.pov であることをプログラムに伝える。 +D スイッチ ( display )はプログラムにグラフィックプレビュー表示がonであることを知らせる。-D はそれをoffに切り替える。数字 "1" はどのタイプのディスプレイを使うかを指示する。タイプ "1" は古い標準の一般的VGAの解像度320x200の256色である。これはすべてのVGAビデオシステムでうまく働くことがかなり保証されている。 あなたがコマンドラインにタイプしたもの以外に効果を持つ別のオプションがある。それらはインストールシステムにより作成された povray.ini というファイルに保存されている。POV-Rayは自動的にこのファイルをpovray.exeのあるディレクトリからさがす。povray.ini と他の INI ファイルに関する詳しい情報は「INI ファイル」および「INI ファイルを使う」を参照しなさい。 あなたが上で示したコマンドを入力すると、POV-Rayが各ピクセルの色を行ごとに計算するにつれ、明るく色づけられた幾何的な形が現れ始めるのを見るだろう。おそらく、あなたはグラフィックディスプレイの結果に失望させられるだろう。それは単にプレビュー表示であるためである。実際のイメージは24-bitフルカラーであるが、我々は256色に固定された単純なVGAを使っているので、その高品質な画像を表示することができない。あなたのハードウェアが標準のVESAインタフェースをサポートするかVESA TSRドライバーがロードされているならば、+D1ではなく+DGで動作させてみてください。これは、あなたのビデオハードウェアが使うことができるいろいろなモードのすべてへのアクセスを与えるだろう。あなたが15-bitか16-bitハイカラー(high color)能力を持つならば、+DGHをためしなさい。あるいは、あなたが24-bitフルカラー能力を持つならば、その栄光の中でイメージを見るために、+DGTをためしなさい。グラフィックプレビューのより詳しい情報は下記のセクション「ディスプレイタイプ」を見なさい。 プログラムが終わるとあなたはピーッという音を聞くだろう。イメージを賞賛したら[ENTER]を押しなさい。あなたは、統計量のテキスト画面を見るだろう。テキストが画面に入りきらなければ[CURSOR UP]か[CURSOR DOWN]キーで表示されていないテキストを読むことができる。タブが画面の下部にあることに気をつけなさい。他の面白いテキスト情報を見るために[CURSOR LEFT]か[CURSOR RIGHT]キー押しなさい。再び[ENTER]を押せばPOV-Rayを抜け出す。 もしあなたがハイカラーもトゥルーカラー能力も持たない場合は、実際の色を見るためにイメージファイルを見なければならない。イメージファイル shapes.tga はあなたのカレントディレクトリに書き込まれている。デフォルトではPOV-RayはファイルをTGAフォーマットで作る。これは24-bitトゥルーカラーイメージを格納するための標準的フォーマットである。あなたはこのファイルを見るためにイメージビューイングプログラムが必要であろう。そのようなプログラムは、たいていあなたがPOV-Rayを得た場所にある。しかしこのパッケージにはビューアーは含まれていない。 あなたが TGA ファイルを見ることができない場合、スイッチ +FN を付けるとPOV-RayはPNG (Portable Network Graphic)フォーマットを出力する。もし PNG フォーマットのビューアーが無い場合は以下のようにタイプしなさい。 T2G SHAPES そして[ENTER]。これはtga2gifプログラムを呼び出すバッチファイルを起動する。プログラムはファイル shapes.tga を読み込んで最適化された256色パレットの GIFフォーマットのファイルshapes.gifを書き出す。ほとんどのイメージビューアは GIFをサポートする。 3.2.1 他のディレクトリにあるファイルの実行 通常POV-Rayは必要とするファイルのために、カレントディレクトリの中に目を向けるだけである。あなたのMS-DOSパスのデータファイルは検索しない；それは、プログラムを捜すだけである。あなたがいま実行したサンプルシーンでは、ファイルshapes.povがカレントディレクトリにあったので、何も問題はなかった。そのシーンは他のファイルも必要とした。しかし、あなたのpovray.iniファイルは必要なファイルを捜す他の場所をPOV-Rayに教える。 あなたがあなたのautoexec.batファイルをアップデートするためにインストールシステムができるならば、あなたは任意のドライブかディレクトリに変更することができて、POV-Rayをそのディレクトリから走らせることができる。また、あなたは任意のディレクトリの中にあるこのパッケージに附属するバッチファイルとユーティリティを使うことができるだろう。後での参照のために 「あなたのパス(path)にc:\povray3を使うプラン」をプラン1と呼ぶ。 あなたがあなたのpathにc:\povray3を置きたくならないいくつかの状況がある。あなたのpathステートメントには128文字の限度があり、それに余裕がない。異なるディレクトリからのサンプルレンダリングを試してみて、それがうまくいかないならば、あなたはあなたのシステムをリブートするのを忘れたので、新しいパスは効果を与えないのだろう。リブートした後に、それがまだうまくいかないならば、多分、それはあなたのパスが満杯だということを意味する。あなたは、異なるプランを採用しなければならないだろう。 すでにあなたのpathにいくつかのディレクトリがあればチャンスがある。ほとんどのシステムではc:\dos、c:\windowsやc:\utilityのような他のディレクトリが既にpathにあるだろう。我々は、あなたがそのディレクトリにコピーすることができるいくつかの小さいバッチファイルを提供した。後での参照のために「すでにpathにあるディレクトリにバッチファイルを置くプラン」をプラン2と呼ぶ。 dosプロンプトで path [ENTER]をタイプする。そうすればpathに設定されているディレクトリが表示される。そしたら以下のファイルをc:\povray3ディレクトリからpathに指定されているディレクトリにコピーしなさい。それのファイルは: RUNPOV.BAT RERUNPOV.BAT RUNPHELP.BAT T2G.BAT これらのファイルをコピーしたならば、以下の例をためしなさい。この場合、コマンドpovrayでプログラムを呼び出さないで、その代わりに次のようにrunpovを使用してください: cd \POVRAY3\POV3DEMO\SHOWOFF RUNPOV +ISUNSET3 +D1 これは、ファイルsunset3.povを探すディレクトリを、\povray3\pov3demo\showoffディレクトリに変更する。そしてそれは、ファイルrunpov.batを実行する。バッチファイルは、たとえPOV-Rayがdosのパスに存在しないとしても、POV-Rayを実行するようにセットアップされている。さらに、スイッチも一緒にPOV-Rayに渡す。あなたが上に述べたプラン1か以下に述べるプラン3を使っているとしても、これらのバッチファイルには別の用途がある。これらのバッチファイルに関してもっと知りたい人は、「バッチファイル」を見てください。 このドキュメントのすべての初期の例では、あなたがPOV-Rayをc:\povray3のようなインストールされたディレクトリから走らせているものと仮定する。常にインストールディレクトリを使用するこのアプローチが、実際、プラン3である。あなたがそれをすることができたsunset3.povの場合: POVRAY +IC:\POVRAY3\POV3DEMO\SHOWOFF\SUNSET3 +D1 しかし、シーンは1つより多くのファイルを必要とする。例えば、\povray3\povscn\level3の下に見つけられるディレクトリdrums2は、3つのファイルを含む:drums.pov、drums.inc と rednewt.gif のすべてのファイルが1つのシーンのために必要である。この場合、あなたはPOV-Rayが捜すライブラリパスを加えるために+Lスイッチ(libraryのL)を使用しなければならない。あなたは、このコマンドでシーンを表現できるだろう。 POVRAY +L\POVRAY3\POVSCN\LEVEL3\DRUMS2 +IDRUMS +D1 3.2.2 INI ファイル これらのレンダリングの中で、あなたが指定したスイッチ+I、+Dと+Lの他にも多くのオプションが使われている。あなたがプログラムを実行する時、POV-Rayは自動的にpovray.exeが存在するディレクトリの中で、ファイルpovray.iniを捜す。ファイルpovray.iniは、POV-Rayがどのように動作するかを制御する多くのオプションを含む。われわれがこのファイルをセットアップしておいたため、あなたは、ほとんど問題なく、とても簡単に最初のシーンを実行することができる。ファイルはpovray.exeと同じディレクトリに置かれなければならない。そして、それはPOV-Rayが実行される時に自動的に読み込まれる。あなたがpovray.exeを異なるディレクトリへ移動する場合、povray.iniも必ず移動して下さい。 コマンドラインとpovray.iniで指定することができるオプションとスイッチの完全な詳細は「POV-Ray のオプション」にある。 また、あなたはpovray.iniと同様のスイッチやオプションを含むINIファイルを作っても良い。もし、あなたがコマンドラインにファイル名をその前にプラスあるいはマイナス符号を付けずに指定すると、POV-RayはそれをINIファイルとして読み込む。これを試して下さい..。 POVRAY RES120 +ISHAPES +D1 これにより、POV-Rayはわれわれが与えたres120.iniというファイルを探す。これはクイックレビューのために解像度を120×90ピクセルにセットする。以下のINIファイルが、あなたのために与えられている。 RES120.INI 解像度を120×90ピクセルにセットする。 RES320.INI 解像度を320×200ピクセルにセットする。 RES640.INI 解像度を640×400ピクセルにセットする。 RES800.INI 解像度を800×600ピクセルにセットする。 RES1K.INI 解像度を1024×768ピクセルにセットする。 LOW.INI 120×90ピクセル低クオリティにセットする。 SLOW.INI ラディオシティーとアンチエイリアシングをonにする; 非常に遅いが美しい。 TGAFLI.INI TGAFLC.INI TGA画像からFLI/FLCアニメーションを作る。 PNGFLI.INI PNGFLC.INI DTA画像からFLI/FLCアニメーションを作る。 ZIPFLI.INI ZIPFLC.INI 圧縮(zipped)画像からFLI/FLCアニメーションを作る。 後述の「アニメーションの手引き」を参照。 あなたはあなた自身のカスタムINIファイルを作ることができる。それらはリファレンスガイド中のすべてのコマンドを含むことができる。 3.2.3 POVRAY.INIに代わるもの povray.iniファイルは、あなたが常時使用したい好みのグローバルなデフォルトオプションを持つことになっている。あなたは、自由に編集し、あなたのニーズに好都合な新しいオプションを設定することができる。しかし、それはpovray.exeと同じディレクトリに置かなければならない。そうしないとそれは見つけられない。dosのパスは捜されないし、povray.iniはコマンドラインスイッチの前に処理されるので、+Lコマンドは助けにならない。 あなたのpovray.exeがCD-ROM上にある場合、あなたはCD上ではpovray.iniを編集することができない。しかし、他の方法がある。あなたは代わりに、グローバルなデフォルトを指定するために環境変数を使用することができる。 あなたのautoexec.batファイルに以下のような行をつけ加える: set POVINI=D:\DIRECT\FILE.INI これはドライブ、ディレクトリ、そして、あなたが選ぶINIファイルをPOVINI環境変数にセットする。あなたがPOVINI環境変数を指定すると、povray.iniは読み込まれない。たとえあなたが名付けたファイルが存在しないとしてもこれはそうなる。あなたが、全パスとファイル名を指定していることに注意してほしい。これは、povray.iniを含んでいるディレクトリへのポインターではない。それは実際のファイル自身へのポインタである。 POV-Rayの以前のバージョンのPOVRAYOPT環境変数は、もはやサポートされないことを注意する。 3.2.4 バッチファイル POV-Rayディレクトリから起動する代わりにrunpov.batをどのように使うことができるかについてはすでに述べた。runpov.batにはもう一つ別の使い方がある。これは+GIスイッチによりrerun.iniと呼ばれるファイルを作る。これは同じファイルを同じパラメータで再び実行することを容易にする。あなたのシーンファイルを作るときに、たぶんあなたは何度もテストレンダリングをするだろう。これは、非常に価値ある機能である。ここにそれがどのように働くか示す...あなたが以下のようにシーンをレンダリングするものとする: RUNPOV +IMYSCENE +D1 RES120 これは、120×90の解像度でmyscene.povをレンダリングする。そのようなシーンは実際には無いことを注意する。これは、仮である。結果を見た後、あなたは、あなたのテキストエディタで修正した間違いに気がついた。シーンを再表示するために: RERUNPOV とタイプしなさい。これだけで良い。それは、あなたが実行したのと同じシーンを再実行する。次回の実行においてより細部を表示したいとする。あなたはスイッチかINIファイルを追加することができる。例えば: RERUNPOV RES320 はより高解像度で再実行する。あなたが異なる値を指定するまで以後のrerunpovの使用においては320×200で実行される。他の例として、+A スイッチはアンチエイリアシング(anti-aliasing:境界のぎざぎざなどを平滑化すること)をonに切り替える。" rerunpov +A "とタイプするとアンチエイリアシングがonの状態で再実行される。以後のすべての再実行はあなたが実行時に " rerunpov -A "によりoffにするまでonで実行される。あなたが新たにrunpovを実行するとpovray.iniのデフォルトから始め、古いrerun.iniをオーバーライトする点に注意して下さい。 他に2つのバッチファイルが含まれている。runphelp.batは、他のディレクトリからpovhelpを実行する代わりの方法として使用されるだけである。あなたがインストールプラン2を使用しているならば、povhelp.exeよりはむしろrunphelp.batを使用しなさい。このバッチファイルの目的はそれだけである。 最後に、t2g.batはTGAファイルをGIFファイルに変換するためにtga2gif.exeプログラムを呼び出す。あなたは直接tga2gifを実行することができる。しかし、通常そのデフォルトパラメータでは最高の結果にはならない。その代わりにT2Gを使用すれば、それはうまく働くコマンドラインスイッチを加える。tga2gifの使用できるスイッチの完全なリストを得るには、パラメータをつけないでtga2gifをタイプすれば、存在するオプションとスイッチが表示される。 3.2.5 ディスプレイタイプ あなたはすでに+D1を使ってグラフィックスプレビューの表示をonに切り替える方法を知っている。ここで+Dスイッチの他のバリエーションの詳細を示す。表示をoffに切り替えるには -Dを使いなさい。あなたが-Dを使用する場合、多分、あなたは+Vを加えたいだろう。これは詳しい状態メッセージの表示をonに切り替え、レンダリングの進行をモニターすることができる。 +Dの後ろの数字"1"はどんな種類のビデオハードウェアを使うかを指定する。もし、+D だけあるいは+D0を指定すると POV-Ray は自動的にあなたのハードウェアのタイプを検出しようとする。 あなたは、また、どんなハードウェアを使用するか、明示的にPOV-Rayに指定することもできる。以下のチャートにすべてのサポートするタイプをリストする。 +D0 自動検出の (S)VGA タイプ (デフォルト) +D1 標準 VGA 320x200 +D2 標準 VGA 360 x 480 +D3 Tseng Labs 3000 SVGA 640x480 +D4 Tseng Labs 4000 SVGA +D5 AT&T VDC600 SVGA 640x400 +D6 Oak Technologies SVGA 640x480 +D7 Video 7 SVGA 640x480 +D8 Video 7 Vega (Cirrus) VGA 360x480 +D9 Paradise SVGA 640x480 +DA Ahead Systems Ver. A SVGA 640x480 +DB Ahead Systems Ver. B SVGA 640x480 +DC Chips & Technologies SVGA 640x480 +DD ATI SVGA 640x480 +DE Everex SVGA 640x480 +DF Trident SVGA 640x480 +DG VESA 標準 SVGA アダプター +DH ATI XL ディスプレイカード +DI Diamond Computer Systems SpeedSTAR 24X 最も一般的なタイプは、+DGを使用するVESA標準のカードである。VESAは、広く多様なカードで機能する標準のソフトウェアインタフェースである。VESAのサポートが直接組み込まれていないカードでも、たいていVESAのサポートを提供するドライバーをロードすることができる。プログラムUniVBEは、あなたのために機能するであろう高品質で統一的なVESAドライバーである。それは、http://www.povray.org/かおそらく他のPOV-Rayサイトで見つけることができる。 先にリストしたオプションは初期のバージョンのPOV-Rayでテストされているが、プログラムに多くの変更があったため今もうまく働くかどうかは保証できない。あなたがVESAを使用することができるならばそうして下さい。それは、よくテストされており、あなたに最も多くの融通性を与える。 +Dとタイプの後ろに、あなたは3つ目の文字でパレットタイプを指定することができる。 +D?3 ディザリングした332パレットを使う(VGAシステムのデフォルトで最良)。 256色の固定パレットで各色は 3-bitsの赤データ、3-bits の緑および2-bitsの 　　　 青からなる。 +D?0 VGAディスプレイ用のHSVパレットを使う。固定256色パレットで、色は赤、緑、 　　　 青の量よりもむしろ色相、彩度、明度に従ってマッチされる。 +D?G VGAディスプレイ用の固定グレイスケールパレットオプション。 +D?H ハイカラーオプションを使う。ディザリングにより32,000色以上を表示する。 VESA、SpeedSTAR 24X、ATI XL HiColor および Tseng 4000 を用いた15あるいは 16ビットハイカラーオプション付きのカードでサポートされる。 +D?T トゥルーカラー 24 bitカード用。24 bit色を使う。Diamond SpeedSTAR 24X と 　　　　24bit VESA をサポートするカードだけである。 いくつかの例を示す: +D0H VGAディスプレイのタイプを自動検出し、それが動作しているものとし イメージをスクリーンに表示する。スクリーンに32000色以上表示する ために15-bitのハイカラーチップかディザリングを用いる。 +D4 TSENG 4000チップセットVGAへの表示。332パレットオプションを用いる。 +D4H TSENG 4000チップセットVGAへの表示。ハイカラーオプションを用いる。 +DG0 VESA VGA アダプターへの表示。HSVパレットオプションを用いる。 +DG3 VESA VGA アダプターへの表示。332パレットオプションを用いる。 +DGH VESA VGA アダプターへの表示。32,000色以上の表示のためにハイカラー オプションを用いる。 +DGT VESA VGA アダプターへの表示。1600万色以上の表示のためにトゥルーカラー オプションを用いる。 注意:あなたがこれらのオプションを使うためには、あなたのVESA BIOSがそれをサポートしていなければならない。いくつかのカードはハイカラーや トゥルーカラーをハードウェアレベルでサポートしているが、そのVESA BIOSを通してはしていないかもしれない。 4 初心者向けの手引き 初心者向けの手引きでは、あなた自身のシーン(scene)をつくるためにどのようにPOV-Rayのシーン記述言語を使うかを一歩一歩説明する。POV-Rayの言語の機能のほとんどすべての使用法が詳細に説明される。あなたは、カメラと光源を置くことのような基本的な事項を学ぶ。また、変化に富んだオブジェクトを創作する方法と様々なテクスチャをそれらに割り当てる方法を学ぶ。さらに、ラディオシティ法(radiosity)、ハローおよび大気の効果(atmospheric effects)のようなより洗練された機能も詳細に説明する。 以下のセクションでは、リファレンス章の中で記述されるのと同じ順序で機能を概略的に説明する。 4.1 われわれの最初のイメージ 単純な絵のシーンファイルをつくろう。レイトレーサーは球の表現によって発展したので最初に球を表現することにする。 4.1.1 POV-Rayの座標系を理解する 第一に、どこに我々のカメラがあり、そして、それがどこを見ているかをPOV-Rayに教えなければならない。そのために、3D座標を使う。POV-Rayの普通の座標系はY軸の正方向は上を示し、X軸の正方向は右側を示して、Z軸の正方向は画面の中を図のように指している: ^+Y | /+Z | / | / -X |/ +X <-------|--------> /| / | / | -Z/ | v-Y 図　左手座標系(z-軸があなたから離れる方向を指している)。 この種の座標系は左手座標系と呼ばれる。なぜそう呼ばれるかは左手の指を用いると簡単にわかる。まず親指をx軸の正の方向に向け、人差し指をy軸の正の方向に向けると、あなたの中指はz軸の正方向を指す。これは左手だけが可能である。もし右手を使ったら中指は正しい向きを指さない。 左手はまた回転方向を決定するのにも用いることができる。それをするためには、有名なコンピュータグラフィックス・エアロビクス運動をしなければならない。左手を挙げて、親指を回転軸の正方向に向けよう。あなたの指のカールする方向が回転の正の方向である。 ^ +Y| +Z/ _ | /_| |_ _ | _| | | |/ \ | | | | | | | | /| | | | | V -X |/ | | | | | +X <----------+--|-|-|-|-|-> /| | ____ / | | ___| / | \ / / | | / -Z/ -Y| / | 図　回転方向を決めるためのコンピュータグラフィックス・エアロビクス 上図のイラストの中で、左手はx-軸のまわりにカールしている。親指はxの正方向を差し、他の指は正回転方向にカールする。 あなたがAutoCADのようないくつかのCADシステムで使われている右手系を使いたいならば、カメラ定義中のright ベクトルを変える必要がある。詳しくは「ハンドネス(Handedness)」を参照してほしい。右手系においては先のエアロビクスのために右手を使うことになる。 注:過去にPOV-Rayの右手系の方法が本当に適当であるかどうかについていくつかの終わった論争があった。あなたが問題を避けたいならば、論争中でない左手系に固執することを勧める。 4.1.2 標準インクルードファイルの追加 あなたの好みのテキストエディタを使って demo.povという名のファイルを作りなさい。そしたら以下のようにタイプしてください(入力は大文字小文字を区別するので、大文字小文字を正確に)。 #include "colors.inc" // インクルードファイルは定義済みの #include "shapes.inc" // シーンエレメントを含む #include "finish.inc" #include "glass.inc" #include "metals.inc" #include "stones.inc" #include "woods.inc" (訳注:上記の//は以後がコメントであることを示す。) 最初のinclude文は様々な役立つ色の定義を読み込む。2番目のinclude文はいくつかの役に立つ形状を読み込む。続く文はあらかじめ定義されたfinishes、glass、metal、stone、および wood テクスチャを読み込む。もしチャンスがあれば理解のためにそれらを通して見てください。もっともそれらは存在する非常に多くの形状とテクスチャの一部であるが。 あなたはあなたのシーンのために本当に必要なファイルだけをインクルードすべきである。POV-Rayと一緒に配布されるいくつかのインクルードファイルは非常に大きいので、それらを読み込まなければ処理時間とメモリを節約することができる。以下の例ではインクルードファイル colors.inc、finish.inc および stones.incを使うだけでよい。したがってシーンファイルから不要な行を取り除いておいた方が良い。 多くのインクルードファイルがシーンファイルで必要になるかも知れない。インクルードファイルがそれ自身インクルードファイルを含む場合がある。しかし、インクルードファイルのネスト(入れ子)は10レベルに制限されている。 インクルード文で指定されたファイル名は最初にカレントディレクトリで探され、見つからないと、+L あるいは Library_Pathオプションで指定されたディレクトリが探される。このことはshapes.inc、colors.inc、や textures.inc のようなすべてのインクルード(.inc)ファイルを"include"サブディレクトリに置いたままで、コマンドラインの+Lオプションでインクルードファイルのライブラリがどこにあるか指定するのを容易にする。 4.1.3 カメラを追加する camera 宣言はカメラがどこからどのようにシーンを見るかを記述する。x、y、z 座標でカメラの位置とシーン上のどの部分を指しているかを指示する。x、y、z 座標は3要素ベクトルで記述する。ベクトルは角括弧<>で囲まれ、コンマで区切られた3つの数値で指定される。 以下のcamera文をシーンに追加する。 camera { location <0, 2, -3> look_at <0, 1, 2> } 簡潔には、位置 <0,2,-3>はカメラをレイトレーシング空間の中心<0,0,0>から上に2単位、後方に3単位に置くことを意味する。デフォルトで +z はスクリーンの奥で -z はスクリーンの手前側である。 また、look_at <0,1,2> はカメラを回転し x、y、z 座標<0,1,2>を指すことを意味する。カメラに比べて 5 単位前で 1 低い点を指す。look_at 点はわれわれのイメージの注目する部分の中心である。 4.1.4 オブジェクトを記述する さて、カメラはシーンを記録するためにセットされたので、黄色の球をシーンに置こう。われわれのシーンファイルに以下を追加する: sphere { <0, 1, 2>, 2 texture { pigment { color Yellow } } } 最初のベクトルは、球の中心を指定する。この例では、x座標はゼロであるので、左右の中心に置かれる。またy=1であるので原点から1単位上に置かれる。z座標は 2であり、5単位z=-3のカメラの前である。中心ベクトルの後のカンマの後にこの場合2単位の半径が続く。半径は球の幅の半分であるから、球の幅は4単位である。 4.1.5 オブジェクトにテクスチャを加える 球の位置とサイズを定義した後、我々は表面の外観を記述する必要がある。 テクスチャ(texture)ブロックはそれらのパラメータを規定する。テクスチャブロックは、オブジェクトのcolor(色)、bumpiness(凹凸)、finish(仕上げ)を記述する。この例では colorだけを指定する。これは最小限指定しなければならないものである。color以外の他のすべてのテクスチャ値はデフォルト値が用いられる。 われわれが定義する color はそれが十分に照明されたときに見える色である。もしわれわれが球の絵を描いているとすると、われわれは陰になる側面を示すために暗い色を使い、明るく照らされた側面を示すために明るい色合いを使うだろう。しかし、レイトレーシングはわれわれのためにその面倒を見てくれる。われわれはオブジェクトに基本的な本来の色を選ぶ、そして、POV-Rayはシーンの中の照明に基づいてそれを輝かせるか暗くする。われわれはオブジェクトがどう見えるかでなく、実際のオブジェクトが持つ基本的な色を定義するのでそのパラメータをピグメント(pigment:色素・顔料・絵の具の意)と呼ぶ。 pigment文の中で使える多くのタイプのカラーパターン(color patterns)がある。キーワードcolorは色の模様(pattern)でなくオブジェクト全体の一定の色(solid color)を指定する。われわれは標準インクルードファイルcolors.incであらかじめ定義されているcolor識別子(identifiers)を使うことができる。 われわれが必要とする色が標準色にない場合、必要な色をcolorキーワードに続くred、green および blue キーワードによって赤、緑、青の混ぜる量を指定できる。たとえばすてきな色合いのピンクは: color red 1.0 green 0.8 blue 0.8 により指定できる。 各キーワードの後ろの値は 0.0 から 1.0の範囲である。指定がない場合の3成分のそれぞれのデフォルトの値は0である。またショートカット表記が利用できる。以下は同じ色合いのピンクを作る: color rgb <1.0, 0.8, 0.8> 4.1.6 光源を定義する 我々のシーンのためにもう一つの項目、光源(light source)が必要である。光源を作るまであなたの仮想空間には光が存在しない。そこで、あなたの最初のPOV-Rayシーンを完成させるために次の行を加えよう light_source { <2, 4, -3> color White} 完成したシーンは以下のようになる。 #include "colors.inc" background { color Cyan } camera { location <0, 2, -3> look_at <0, 1, 2> } sphere { <0, 1, 2>, 2 texture { pigment { color Yellow } } } light_source { <2, 4, -3> color White} light_source文のベクトルは光源が原点から 2単位右、4単位上 3単位後ろであることを意味する。光源は見えない。光を放つだけである。したがってテクスチャは必要ない。 さあ、ファイルを閉じて以下のコマンドを使って小さな絵をレンダリングしよう povray +w160 +h120 +p +x +d0 -v -idemo.pov われわれのコンピュータがコマンドラインを使わない場合は、レンダリングするための正しいコマンドを特定のプラットホーム用の文書から見つけなければならない。 また、われわれは好みに応じて他のコマンドラインオプションをセットすることができる。シーンはイメージファイル demo.tgaに書き込まれる (あるいはわれわれのコンピュータのデフォルトのファイル形式が異なる場合は.tga以外の拡張子のファイルかも知れない)。 (図 あなたの最初の本当に簡単なPOV-Rayシーン) われわれがトレースしたこのシーンはまだアートにはほど遠いが、より魅力的な機能とシーンにたどり着く前に基礎から出発しなければならない。 4.2 カメラを使う 4.2.1 焦点ぼけ(Focal Blur)を使う 焦点ぼけの使用を説明するために、単純なシーンを作ろう。この例のために、ピンクの球、緑のボックスおよび青い円筒を使い、球は前景に、ボックスは中央に、円筒を背景に置くものとする。遠近法のためのチェッカー模様の床、一組の光源でシーンは完成する。 focaldem.povという名の新しいファイルを作成し、以下のテキストを入力しよう #include "colors.inc" #include "shapes.inc" #include "textures.inc" #version 3.0 global_settings { assumed_gamma 2.2 // ほとんどのPCモニタ用 max_trace_level 5 } sphere { <1, 0, -6>, 0.5 finish { ambient 0.1 diffuse 0.6 } pigment { NeonPink } } box { <-1, -1, -1>, < 1, 1, 1> rotate <0, -20, 0> finish { ambient 0.1 diffuse 0.6 } pigment { Green } } cylinder { <-6, 6, 30>, <-6, -1, 30>, 3 finish { ambient 0.1 diffuse 0.6 } pigment {NeonBlue} } plane { y, -1.0 pigment { checker color Gray65 color Gray30 } } light_source { <5, 30, -30> color White } light_source { <-5, 30, -30> color White } これでわれわれの焦点ぼけカメラを適当な視点に置くことを続けることができる。我々の三つのオブジェクトから真っ直ぐ後ろなら、素晴らしい視界を生むだろう。focal_point(焦点位置)の調整でシーンのどこにでも焦点位置を移動できる。ファイルに以下の行を加えるだけである。 camera { location <0.0, 1.0, -10.0> look_at <0.0, 1.0, 0.0> // focal_point <-6, 1, 30> // 青い円筒に焦点 // focal_point < 0, 1, 0> // 緑のボックスに焦点 focal_point < 1, 1, -6> // ピンクの球に焦点 aperture 0.4 // ちょうど良い中間値 // aperture 0.05 // ほとんどすべてが焦点内 // aperture 1.5 // 多いぼけ // blur_samples 4 // 少しのサンプル、高速なレンダリング blur_samples 20 // たくさんのサンプル、高品位のイメージ } focal point(焦点)は単純にカメラのフォーカスが最もシャープになる点である。われわれはこの点をシーンに置き、焦点の合った領域からぼけがどのくらい近くあるいは遠く離れたところに起こって欲しいかを調整するためにaperture(絞り値)に値を割り当てる。 apertureの設定は焦点の範囲とみなすことができる。絞りを開くと焦点の合う領域を狭くし、より小さな絞りの値は焦点の合う領域を広くする。これが焦点のまわりにどのように焦点ぼけが起こるかをコントロールする方法である。 blur samples(ぼけのサンプル)の設定はどれくらい多くの光線が各ピクセルのために採られるかを決める。基本的には、多くの光線の使用は最終的なイメージをより高品質にするが、より長いレンダリング時間がかかる。各シーンは様々になるので実験しなければならない。このチュートリアルには4および20のサンプルの例があるがより高解像度のイメージにはもっと多く使うことができる。より多くのサンプルはより多くのレンダリング時間がかかるので、要求される品質を成し遂げるのに必要な以上のサンプルを使うべきではない。confidence(信頼)とvariance(変動)の設定は、セクション「焦点ぼけ」に含まれる。 われわれはfocal point、apertureおよびblur sampleの設定の実験を行う。シーンにはデフォルトの行をダブルスラッシュでコメントアウトし、試したい行をコメントでなくすことにより試すことができる他の値の行がある。われわれはシーンにおけるその効果を見るために一度に一つの変更だけを行う。 焦点ぼけカメラを用いたシーンをトレーシングするときの決定的な2つを示す。われわれはアンチエイリアス(+Aスイッチ)を指定する必要はない。なぜならば焦点ぼけのコードは自動的にアンチエイリアシングの面倒をみてくれるその一つのサンプリング法を用いるからである。焦点ぼけは透視投影カメラ(perspective camera)にだけ用いることができる。 4.3 単純な形状 今までのところ、我々はただ球形を使っただけである。POV-Rayで表現できる多くの他の種類の形がある。以下のセクションでは上で用いた球の置き換えとして使えるいくつかの単純なオブジェクトについて述べる。 4.3.1 ボックスオブジェクト ボックス(box)は最も一般的に使われるオブジェクトの一つである。次の例をsphereの記述の代わりに試してみよう。 box { <-1, 0, -1>, // 手前・下・左角 < 1, 0.5, 3> // 奥・上・右角 texture { T_Stone25 // stones.incで定義済み scale 4 // 全方向を同じ量でスケーリング // } rotate y*20 // "rotate <0,20,0>"と同じ } この例で、boxがその対角頂点の座標を指定することによって定義されることが分かるだろう。最初のベクトルは最小の x、y、z 座標で、第2のベクトルは最大の x、y、z値でなければならない。オブジェクトはワールド座標系の座標軸に平行に定義しなければならない。その後任意の角度で回転させることができる。あなたは数値とベクトルの簡単な計算ができなければならない。rotateのパラメータにおいてベクトル識別子yに20を掛けた。これは <0,1,0>*20 あるいは <0,20,0>と同じである。 4.3.2 コーン オブジェクト 以下はコーン(Cone:円錐)をどう使うかを示すための例である。 cone { <0, 1, 0>, 0.3 // 一端の中心と半径 <1, 2, 3>, 1.0 // 他端の中心と半径 texture { T_Stone25 scale 4 } } コーンの形状は上面および底面の中心と半径により定義される。この例では一方の端が <0,1,0> で半径 0.3、他方が中心<1,2,3> 半径=1である。鋭い頂点の円錐がほしければ半径radius=0を使いなさい。端面(end caps)は互いに平行でコーンの軸に直交している。もし、端面のないオープンコーンがほしい場合はopenキーワードを第二半径の後に次のように加えればよい: cone { <0, 1, 0>, 0.3 // 一端の中心と半径 <1, 2, 3>, 1.0 // 他端の中心と半径 open // 端面を取り除く texture { T_Stone25 scale 4 } } 4.3.3 円筒 オブジェクト 円筒(Cylinder:シリンダー)は以下のように定義できる: cylinder { <0, 1, 0>, // 一端の中心 <1, 2, 3>, // 他端の中心 0.5 // 半径 open // 端面を取り除く texture { T_Stone25 scale 4 } } 4.3.4 平面(Plane) オブジェクト コンピュータグラフィックスでお馴染みの格子模様の床(Checkered Floor)を試してみよう。最初に作った球のあるdemo.povファイルに以下のオブジェクトを加えよう。 plane { <0, 1, 0>, -1 pigment { checker color Red, color Blue } } ここで定義したオブジェクトは無限平面である。ベクトル <0,1,0> は平面の表面法線(つまり、あなたがその表面に立ったときのまっすぐ上を示す法線の点である)それに続く数値は原点からその法線に沿った平面の移動量である。この場合床は y=-1に位置し、従って y=1、radius=2の球はその上に載っている。 texture {... }文がないことに注意してほしい。暗示されたテクスチャが実際はある。texture {pigment {... }}のような入れ子の文を続けてタイプするのは面倒である。そこで POV-Ray は多くの状況の下でtexture {... }を取り外すことが可能になっている。一般にtextureブロックはtexture識別子で囲まれたT_Stone25(別記)の例のような場合か階層化テクスチャを作る場合(後述)だけに必要となる。 この pigment はチェッカーカラーパターンを使い、赤と青の2色の色を使うことを指定する。 ベクトル <1,0,0>、<0,1,0> および <0,0,1>は使用頻度が高いため POV-Rayはこれを簡単に指定するための3つの組み込みベクトル識別子 x、y、および z を持つ。これを用いると平面は plane { y, -1 pigment {... } } で定義される。 注意:ベクトル識別子には角括弧<>は使わない。 (図チェッカーボードの上にある球) レンダリングされた床を見るとボールの影が床に見える。影はレイトレーサーによって非常に正確に計算され、はっきりとした鋭い影を作る。現実の世界では半影(penumbral)あるいは柔らかい影がしばしば見られる。後にあなたは柔らかい影のための拡張された光源を用いる方法を学ぶ。 4.3.5 標準インクルードオブジェクト 標準インクルードファイル shapes.incはあらかじめ定義された1単位サイズの半径の球のような形状が定義されている。これは以下のように呼び出すことができる: #include "shapes.inc" object { UnitBox texture { T_Stone25 scale 4 } scale 0.75 rotate <-20,25,0> translate y } 4.4 高度な形状 POV-Rayの持つ単純な形状を用いていくらか経験をつんだら、今度はより高度でスリリングな形状を修得する時である。 以下に記述する形状を理解することは、とるに足らないことではないということを知っていなければならない。どのようにそれらを使うのか、どのようにそれらが働くのか知らなくても心配はいらない。とにかくサンプルを試してリファレンスの章で述べられる機能を使ってみよう。学ぶにはやってみるのが一番だ(There is nothing better than learning by doing)。 4.4.1 双三次パッチ(Bicubic Patch) オブジェクト (訳注:本節の例題を実行するためにはMorayという名のDOS-SVGA用オブジェクト作成プログラム(モデラー)が必要です。Morayが使えない場合はサンプルテキストをカットアンドペーストして、トレースを行って機能を理解してください) 双三次あるいはベジェ(Bezier)パッチは、ほんの数個の制御点を使って表面の定義を簡単に可能とするので役に立つ表面表現である。レイトレーシング(あるいはレンダリング)ではパッチは三角形を用いて近似される。制御点はパッチの形を決定するのに使われる。三角形の頂点を定義する代わりに、あなたは単に制御点の座標を与える。一つのパッチは16個の制御点を持つ。4つの角と残りはパッチをより小さいセクションに分割するために置かれる。ベジェパッチはほとんど常にサードパーティーのモデラーを用いて作られる。この手引きでは、われわれはモデラープログラムMorayを使う(ベジェパッチとPOV形式のファイルをサポートする他のモデラーはどれでも使える)。われわれはMorayをパッチだけを作るために使い、シーンの他のエレメントには用いない。 ベジェパッチは実際に非常に役に立つ。また、わずかの練習でかなり驚くべき物を作ることができる。最初のチュートリアルとして、シングルシートパッチ(single sheet patch)を用いた円錐形のテント小屋(teepee)の一種を作ってみよう。 まず、Morayを走らせ、メインの編集画面(main edit)で"CREATE"をクリックする。そして、"Bezier Patches"を選び、Teepeeという名前をつける。そうすると"CREATE BEZIER PATCH"というダイアログボックスがでてくる。"SHEET"が選択されている事を確認したら、"OK, CREATION"をクリックし、下にあるメインの編集画面から"EXTENDED EDIT"をクリックする。 カーソルを"TOP"の編集画面上にもっていき、右クリックを押しポップアップメニューを出す。"MAXIMIZE"をクリックし、[ALT]を押しながらマウスを移動させ、少々拡大する。"MARK ALL"をクリックし下のtransformation mode boxから"UFRMSCL"を選択する。Patchを拡大するために、だいたい4単位ぐらいの大きさになるまで、[ALT]を押したままマウスを移動する。それから"TRANSLATE"をクリックし、Patchの中央部分を起点にするために、Patchを中央に移動させる。右クリックし、メニューから"MINIMIZE"を選び、"UNMARK ALL"を選ぶ。 右のいちばん下の設定点をマークするために、[SHIFT]を押しながらマウスを移動させ現れる正方形で1点を囲う。"FRONT"の編集画面上で、Patchをよくみることができるようにするため、[ALT]を押したままマウスを移動させ、拡大させる。"FRONT"編集画面上で正のZ軸方向に沿って10単位移動させる。(注:MorayではZ軸が上方)そして、"UNMARK ALL"を押す。他の3点についても同様の作業を繰り返す。それぞれの点を移動させる度ごとに、"UNMARK ALL"を押し忘れていないかを確認する。4つの支柱で支えられているような形状ができあがっていると思う。そしたら、"UNMARK ALL"を押す。 もう1度"TOP"の編集画面で作業する。[SHIFT]を押しながらマウスを移動させ、中央の4つの設定点をマークするために現れる正方形で4つの点を囲う。"MAXIMIZE"をクリックし、そして"UFRM SCL"を選び、4つの点が近くに一緒になるように左ボタンを押したままマウスを移動させる。[ALT]を押したまま、マウスを移動させ、画面を拡大し、できる限り4点が近づく様に4点を移動させる。[ALT]を押したまま、マウスを移動させ縮小し、右クリックし、"MINIMIZE"を選ぶ。 "FRONT"の編集画面に行き、マークされているポイントをZ軸方向にそって10単位移動させる。"UNMARK ALL"を押す。できあがった形状は簡単に作れて、プリミティブを使ったCSGでは作れない、とってもおもしろい形に仕上がったと思う。さあ、それではこれを画像にとりいれてみましょう。 DONEをクリックし、メインの編集画面にもどる。U_STEPSとV_STEPSのどちらも3になっていてFLATNESSも0.01にセットされている事に注目する。今はこのままにしておく。"FILES"をクリックし、"SAVE SEL"(save selection)を押し、作成したデータにteepee1.mdlと名づけ保存する。[F3]を押しteepee1.mdlを開く。オリジナルファイルはセーブする必要はない。teepee1.mdlを開いた時に、"見本"のテクスチャを手短に作る(Morayではテクスチャなしではデータをexportできない)。ディフォルトの設定で、白色のテクスチャを作り、それに、TeePeeTexという名をつけ、作ったオブジェクトに張り付ける。ファイルを保存して、[CTRL-F9]を押す。すると、Morayはteepee1.incとteepee1.povという2つのファイルを生成する。 Morayを終了し teepee1.inc および teepee1.povをあなたがこのチュートリアルで使っている作業ディレクトリにコピーする。新しいファイル bezdemo.pov を作り、以下のように編集する: #include "colors.inc" camera { location <0,.1, -60> look_at 0 angle 36 } background { color Gray25 } //パッチが見やすくなるように light_source { <300, 300, -700> White } plane { y, -12 texture { pigment { checker color Green color Yellow } } } テキストエディタを使って、テント小屋オブジェクトのための宣言と簡単なテクスチャを記述する: #declare TeePeeTex = texture { pigment { color rgb <1, 1, 1,> } finish { ambient.2 diffuse.6 } } teepee1.pov からベジェパッチデータをペーストする(Morayにより加えられた他のオブジェクトの定義は削除した): bicubic_patch { type 1 flatness 0.0100 u_steps 3 v_steps 3, <-5.174134, 5.528420, -13.211995>, <-1.769023, 5.528420, 0.000000>, <1.636088, 5.528420, 0.000000>, <5.041199, 5.528420, -13.003932>, <-5.174134, 1.862827, 0.000000>, <0.038471, 0.031270, 18.101474>, <0.036657, 0.031270, 18.101474>, <5.041199, 1.862827, 0.000000>, <-5.174134, -1.802766, 0.000000>, <0.038471, 0.028792, 18.101474>, <0.036657, 0.028792, 18.101474>, <5.041199, -1.802766, 0.000000>, <-5.174134, -5.468359, -13.070366>, <-1.769023, -5.468359, 0.000000>, <1.636088, -5.468359, 0.000000>, <4.974128, -5.468359, -12.801446> texture { TeePeeTex } rotate -90*x // オブジェクトの向きを左手側に向ける rotate 25*y // 4本の「脚」が良く見えるように } 上記の回転を加えなさい。そうするとパッチはPOVの左手座標系の向きに合わせられ、(パッチを作ったMorayは右手座標系である) 4つの脚すべてを見ることができる。200x150-aでレンダリングすると予想通りのかわいい緑と黄色のチェッカー平面の上の白いテント小屋を見る。もう少し近くで見るために、もう一度今度は320x200でレンダリングしよう。 今度は我々は何かまずい物を見る。特に頂点の近くで、まるでファセット(faceting:切り子面)のように鋭く曲がっているのが見られる。これは確かにファセットの一種であり U_STEPS および V_STEPS パラメータによる。これらを 3 から 4に変え、何が起こるか見てみよう。 大分良くなるが、レンダリングに少しよけいに時間がかかる。これは、トレードオフ(不可避の見返り)である。あなたがさらに細かいディテールが欲しいならば、U_STEPSとV_STEPS値に5を使って、flatnessを0に調整しなさい。しかし大量のメモリとさらにより長いトレーシング時間がかかる。 さて、このシーンをこのままにしおかないで興味深い2つのアイテムを追加しよう。パッチオブジェクトを宣言し、それらのいくつかをシーンの周りに散らしてみよう: #declare TeePee = bicubic_patch { type 1 flatness 0.0100 u_steps 3 v_steps 3, <-5.174134, 5.528420, -13.211995>, <-1.769023, 5.528420, 0.000000>, < 1.636088, 5.528420, 0.000000>, < 5.041199, 5.528420, -13.003932>, <-5.174134, 1.862827, 0.000000>, < 0.038471, 0.031270, 18.101474>, < 0.036657, 0.031270, 18.101474>, < 5.041199, 1.862827, 0.000000>, <-5.174134, -1.802766, 0.000000>, < 0.038471, 0.028792, 18.101474>, < 0.036657, 0.028792, 18.101474>, < 5.041199, -1.802766, 0.000000>, <-5.174134, -5.468359, -13.070366>, <-1.769023, -5.468359, 0.000000>, < 1.636088, -5.468359, 0.000000>, < 4.974128, -5.468359, -12.801446> texture { TeePeeTex } rotate -90*x // オブジェクトの向きを左手側に向ける rotate 25*y // 4本の「脚」が良く見えるように } object { TeePee } object { TeePee translate <8, 0, 8> } object { TeePee translate <-9, 0, 9> } object { TeePee translate <18, 0, 24> } object { TeePee translate <-18, 0, 24> } なかなかいいでしょう。退屈なグレーの背景を何とかしよう。background 宣言を消して以下と置き換えよう: plane { y, 500 texture { pigment { SkyBlue } finish { ambient 1 diffuse 0} } texture { pigment { bozo turbulence.5 color_map { [0 White] [1 White filter 1] } } finish { ambient 1 diffuse 0 } scale <1000, 250, 250> rotate <5, 45, 0> } } これは心地よい巻雲で満たされた空を加えることになる。今度はチェッカー平面を波紋が起きた砂丘に変えてみよう: plane {y,-12 texture { pigment { color <.85,.5,.15> } finish { ambient.25 diffuse.6 crand.5 } normal { ripples.35 turbulence.25 frequency 5 } scale 10 translate 50*x } } これを320x240 -aでレンダリングしよう。悪くないね。もう一つだけオブジェクトエレメントを加えてみよう。それぞれのテント小屋の下に金の卵を置いてみよう。そしてこれはベジェパッチのチュートリアルだから、ベジェパッチで卵を作ってみよう。 Morayに戻って別のベジェパッチを作ろう。名前はEgg1と名付け、"CREATE BEZIER PATCH"ダイアログボックスから、"CYLINDE(2-PATCH)"を選択する。"EXTENDED EDIT"をクリックし、"MARK ALL"を選ぶ。cylinderを横にするために回転(rotate)させる。"FRONT"の編集画面にいって、下の4つの設定点をマークするために、[SHIFT]を押したまま、マウスを移動させて現れる正方形で4点を囲む。"SIDE"編集画面にいって、右クリックし、"MAXIMIZE"を選ぶ。[ALT]をおしたまま、マウスを移動させ、多少拡大する。"UFRM SCL"を選び、できるだけ4点が、近づくようにする。よりきれいに、隙間無く閉じるようにするために拡大をする。そして、縮小し、右クリックし、"MINIMIZE"を選ぶ。 TRANSLATEをクリックし、隣の4つの設定点とZ軸上で一直線上になるように、左に移動する。この作業で、卵の先の丸い形をpatchに作り出す事ができる。反対の端も同じような作業を繰り返す。その後"UNMARK ALL"を押す。 "FRONT"の編集画面にいき、コントロールグリットは長方形になっており、patchは楕円体になっていると思う。コントロールグリットをマークするため、[SHIFT]を押しながらマウスを移動させ、上方の右のかどの設定点を囲む。また、下方の右のかども[SHIFT]を押しながらマウスを移動させ囲んで、マークする。"SIDE"の編集画面にいき、"UFRM SCL"を選択し、上の方より多少広がる卵の下の方の形を作るため、外に広げる。そして、"UNMARK ALL"を押す。 卵は適度に均整のとれた形に調節する必要がある。本物の卵のように見えるようになるまで、3つの画面の中で"LOCAL SCL"と"MARK ALL"を使って変形することができる。満足のいく形ができたら、"UNMARK ALL"をクリックし、DONEをおす。テント小屋(teepee)を作った時覚えたように、先の作業をし、U_STEPSとV_STEPSの値を4に変えよう。 ダミーテクスチャを作り、デフォルトの設定で、白色のテクスチャを作り、それに、EggTexという名をつけ、卵に張り付ける。ファイルメニューから、"SAVE SEL"を選びegg1.mdlという名でファイルを保存する。そして、ファイルを開き、イクスポート(export)する([CTRL-F9])。Morayを終了し、egg1.incとegg1.povという2つのファイルを作業ディレクトリに移動させる。 bezdemo.povに戻って、素晴らしい輝く金のテクスチャを作ろう: #declare EggTex = texture { pigment { BrightGold } finish { ambient.1 diffuse.4 specular 1 roughness 0.001 reflection.5 metallic } } TeePeeTexテクスチャをもっとダンディにしよう : #declare TeePeeTex = texture { pigment { Silver } finish { ambient.1 diffuse.4 specular 1 roughness 0.001 reflection.5 metallic } } 卵のパッチデータにペーストして卵を宣言しよう: #declare Egg = union { // Egg1 bicubic_patch { type 1 flatness 0.0100 u_steps 4 v_steps 4, < 2.023314, 0.000000, 4.355987>, < 2.023314, -0.000726, 4.355987>, < 2.023312, -0.000726, 4.356867>, < 2.023312, 0.000000, 4.356867>, < 2.032037, 0.000000, 2.734598>, < 2.032037, -1.758562, 2.734598>, < 2.027431, -1.758562, 6.141971>, < 2.027431, 0.000000, 6.141971>, <-1.045672, 0.000000, 3.281572>, <-1.045672, -1.758562, 3.281572>, <-1.050279, -1.758562, 5.414183>, <-1.050279, 0.000000, 5.414183>, <-1.044333, 0.000000, 4.341816>, <-1.044333, -0.002947, 4.341816>, <-1.044341, -0.002947, 4.345389>, <-1.044341, 0.000000, 4.345389> } bicubic_patch { type 1 flatness 0.0100 u_steps 4 v_steps 4, < 2.023312, 0.000000, 4.356867>, < 2.023312, 0.000726, 4.356867>, < 2.023314, 0.000726, 4.355987>, < 2.023314, 0.000000, 4.355987>, < 2.027431, 0.000000, 6.141971>, < 2.027431, 1.758562, 6.141971>, < 2.032037, 1.758562, 2.734598>, < 2.032037, 0.000000, 2.734598>, <-1.050279, 0.000000, 5.414183>, <-1.050279, 1.758562, 5.414183>, <-1.045672, 1.758562, 3.281572>, <-1.045672, 0.000000, 3.281572>, <-1.044341, 0.000000, 4.345389>, <-1.044341, 0.002947, 4.345389>, <-1.044333, 0.002947, 4.341816>, <-1.044333, 0.000000, 4.341816> } texture { EggTex } translate <0.5, 0, -5> // 原点のまわりに卵を中心に置く translate -9.8*y // 卵を地面の上に置く } 卵のコピーをテント小屋の下に配置しよう。それにはそれぞれのテント小屋の xとz座標が必要である。 object { Egg } object { Egg translate <8, 0, 8> } object { Egg translate <-9, 0, 9> } object { Egg translate <18, 0, 24> } object { Egg translate <-18, 0, 24> } 図 シーンが様々なベジェパッチで作成される。 これを 320x240 -Aでレンダリングしよう。すべてがうまくいっているように見えたらこんどは 640x480 +Aでやろう。 まだ、いくらかのファセット(faceting:小面)がテント小屋の頂上の近くと卵の上にあるのが見える。これの唯一の解決策は U_STEPS と V_STEPSを4から5に増やし、すべてのベジェパッチの flatness を 0 にすることである。変更を加えてから 640x480 +Aで再びレンダリングしよう。 4.4.2 ブロブ※(Blob) オブジェクト (※訳注:Blobはインクなどのしみや、ぼんやりとした形のものを指す。その生成方法から濃度球とも呼ばれる。「メタボール」も生成原理は同じである。) ブロブ(Blobs)はくっつくために滑らかに伸びる"べたつくもの(goo)"で覆われた球と円筒として記述される(セクション「ブロブ:Blob」を見なさい)。原子や分子のモデリングには理想的であり、また、ブロブは多くのなめらかな流れるような「有機的な」形を作成するための強力なツールである。 もう少し数学的にブロブを説明すると、それが2つあるいはそれ以上のコンポーネント(構成要素)部分からなる一つのオブジェクトであるといえる。各部品は実際には見えない力のフィールドで、それは特定の強度で始まり、与えられた半径でゼロまで滑らかに減退する。空間でこれらの部品が重なり合う場所で、それらのフィールドの強度は互いに加算される(そう、そして総計から減算される負の強度を持たせることもできる)。ブロブにはたった一種類だけのコンポーネントを持つことができたが、それが何のように見えるかということは些細な点である。ブロブの実際の美しさはコンポーネントがお互いに影響し合うことによるからである。 最初に簡単なブロブの例を採用しよう。現在、実際は2つの異なるタイプのコンポーネントがあるがそれは後で見ることにしよう。単純な最初の例のために、ただ球形のコンポーネントについてだけ話そう。ここに基本的なカメラ、光源および単純な2つのコンポーネントのブロブが示されている簡単なPOV-Rayコードの例がある(このシーンをblobdem1.povと呼ぶ。): #include "colors.inc" camera { angle 15 location <0,2,-10> look_at <0,0,0> } light_source { <10, 20, -10> color White } blob { threshold .65 sphere { <.5,0,0>, .8, 1 pigment {Blue} } sphere { <-.5,0,0>,.8, 1 pigment {Pink} } finish { phong 1 } } 図 簡単な、2部品のブロブ。 threshold(閾値)は、単にブロブが見えるようになる全強度値である。強度が閾値にマッチするブロブの範囲内の点は、正確にブロブ形の表面を形づくる。この閾値より小さければブロブの外側であり、大きければブロブの内側である。 球形のコンポーネントは、単純な球オブジェクトにとても似ていることに注意しよう。sphereキーワードがあり、ベクトルは球の中心位置を与え浮動小数点数値は球の半径を与える。でも最後の浮動小数点数値は何だろう?これはそのコンポーネントの個々の強度(strength)である。球状のコンポーネントでは、それは球の中心でフィールドがどれくらいの強度かである。それは球の半径において正確にゼロになるように線形の進行で減退する。 このテストイメージをレンダリングする前に、各コンポーネントに異なるピグメントを与えたことを注意する。POV-Rayはブロブのコンポーネントに別々のテクスチャを与えることが可能である。われわれはブロブのどの部分がそれぞれかをはっきりさせるためにそれをここで行った。われわれはまた、最後のfinish文のように、すべてのブロブを一つの物としてテクスチャ付けする事もできる。それがすべてのコンポーネントの外側に最後に現れるのですべてのコンポーネントに適用される。われわれはこのシーンをレンダリングし、基本的なキスしている球状タイプのブロブを得る。 われわれが見るイメージは両側に球が現れるが、それらは滑らかに中心の橋の部分でくっついている。この橋は2つのフィールドが重なる場所を示している。すなわち、ブロブの他の部分より長く閾値の上にある。もしそれがあまり明白ではない場合は、われわれのシーンに以下の2つのオブジェクトを加えて再レンダリングしよう(ファイルblobdem2.povを見て下さい)。 これらはブロブ内のさらなるコンポーネントとしてではなく、別の球オブジェクトとして入力されることを意味することを注意する。 sphere { <.5,0,0>, .8 pigment { Yellow transmit .75 } } sphere { <-.5,0,0>, .8 pigment { Green transmit .75 } } 図　球状のコンポーネントを見えるようにする。 今、キスしている球の秘密が明らかにされた。これらの半透明な球は、ブロブのコンポーネントが実際にあるところを示す。もしわれわれが以前にブロブで作業をしたことがなければ、我々が、ただつけ加えた球が実際にブロブ上でショーアップするだけの球ではなく、よりはるかに範囲を広げるのを見て驚いたかも知れなかった。もちろんそれは我々の球が最初の強度を1にされ、それが球の中心から離れるにつれ徐々に0に漸減するからである。強度が閾値(この場合0.65)よりも下がると、球の残りの部分はブロブの外側になり、したがって見えなくなる。 2つの透明な球がオーバーラップする部分を見なさい?それが正確に2つの球の間の橋に対応していることを注意する。それは2つのコンポーネントの両者がその点でのブロブの全部の強度に寄与している領域である。これがなぜ橋が現れるかである:2つの球のコンポーネントの強度の組み合わせが、そこでオーバーラップするために、その領域は高くて閾値以上にとどまるのに十分な強度を持つ。 4.4.2.1 コンポーネントのタイプと他の新しい機能 今までのところ示された形は面白いが限られたものである。しかしPOV-Rayは、有用性の範囲を広げるいくつかの他の秘訣を備えている。例えば既に見たようにブロブのコンポーネントに個々のテクスチャを割り当てることができる。また、要求に応じてブロブを引き伸ばし、ねじり、押しつぶすために個々の変換(translate、rotateおよびscale)を適用することができる。そして多分、最も興味深いのはブロブのコードが円筒コンポーネントを許すように拡張されたことである。 円筒の解説に移る前に、多分、以前のバージョンのPOV-Rayで使われていた旧スタイルのコンポーネント(component)がまだ動作することを指摘しておくべきであろう。そこに戻ると、すべてのコンポーネントは球であったので、球(sphere)か円筒(cylinder)かを指定する必要は無かった。旧スタイルのcomponentは: component STRENGTH, RADIUS,
の形であった。 ちょうど既に上で見たように、これは球状コンポーネントと同一の効果を持つ。これは後方互換性のためだけに役立つ。もしわれわれがすでに初期のバージョンからのブロブを持つPOV-Rayファイルを持っていると、それがこれらのコンポーネントを認める必要がある場合である。旧スタイルのcomponentは強度、半径、中心のまわりに波括弧は置かなかった。そしてもちろん個々にそれらに変換やテクスチャ付けはできなかった。したがってもし古い作品を新しいバージョンに修正している場合、とにかく旧いスタイルのコンポーネント(component)を球状コンポーネント(spherical component)に変えることは議論する余地はあるが利益があるだろう。 新しくて異なる何かのために:円筒状コンポーネント。われわれがブロブでラフな円筒状の部分を作るためにかつて必要だったもののすべては直線に沿った球状コンポーネントの一連の列であったということを論ずるべきであった。どちらが良いか。もし余分なタイプをすることが好きで、そしてまたその円筒はある軸に沿って向いていると仮定する。そうでなければ、われわれはそれが直線を保つように各コンポーネントの数学的位置を解かなければならないだろう。でももういらない!円筒状のコンポーネントが登場した。 最後の例のblobを以下で置き換えて再レンダリングしよう。ところで、透明な球も除くことができる。 blob { threshold .65 cylinder { <-.75,-.75,0>, <.75,.75,0>, .5, 1 } pigment { Blue } finish { phong 1 } } コンポーネントはたった一つだけなので、円筒状コンポーネントの基本的な形を見ることができる。これは完全な真の円筒ではなく - よりソーセージ形で、2つの半球によっておおわれた円筒である。それは直線に沿って接近して糸に通された球状コンポーネントの配列だったと考えることができる。 コンポーネント宜言それ自身に関しては:我々がどう見えるか予期する点では単純で論理的で正確である(我々が今までに気づいている範囲では):それは円筒オブジェクトの宣言にとても似ていて、ベクトルで2つの端点を指定し、浮動小数点数で円筒の半径を与える。最後の浮動小数点数はもちろんそのコンポーネントの強度である。ちょうど球形のコンポーネントと同様に、強度はその仲間のコンポーネントとこのコンポーネントの相互作用の性質と程度を決めるだろう。実際次に、この仲間に影響し合う何かを与えよう。いいかい？ 4.4.2.2 複雑なブロブの構成と負の強度 新しいPOV-Rayファイルblobdem3.povから始めて、このなんだか少し複雑な例を入力しよう: #include "colors.inc" camera { angle 20 location<0,2,-10> look_at<0,0,0> } light_source { <10, 20, -10> color White } blob { threshold .65 sphere { <-.23,-.32,0>,.43, 1 scale <1.95,1.05,.8> } //手のひら sphere { <+.12,-.41,0>,.43, 1 scale <1.95,1.075,.8> } //手のひら sphere { <-.23,-.63,0>, .45, .75 scale <1.78, 1.3,1> } //手の中間 sphere { <+.19,-.63,0>, .45, .75 scale <1.78, 1.3,1> } //手の中間 sphere { <-.22,-.73,0>, .45, .85 scale <1.4, 1.25,1> } //後部 sphere { <+.19,-.73,0>, .45, .85 scale <1.4, 1.25,1> } //後部 cylinder { <-.65,-.28,0>, <-.65,.28,-.05>, .26, 1 } //小指の下部 cylinder { <-.65,.28,-.05>, <-.65, .68,-.2>, .26, 1 } //小指の上部 cylinder { <-.3,-.28,0>, <-.3,.44,-.05>, .26, 1 } //薬指の下部 cylinder { <-.3,.44,-.05>, <-.3, .9,-.2>, .26, 1 } //薬指の上部 cylinder { <.05,-.28,0>, <.05, .49,-.05>, .26, 1 } //中指の下部 cylinder { <.05,.49,-.05>, <.05, .95,-.2>, .26, 1 } //中指の上部 cylinder { <.4,-.4,0>, <.4, .512, -.05>, .26, 1 } //人差し指の下部 cylinder { <.4,.512,-.05>, <.4, .85, -.2>, .26, 1 } //人差し指の上部 cylinder { <.41, -.95,0>, <.85, -.68, -.05>, .25, 1 } //親指の下部 cylinder { <.85,-.68,-.05>, <1.2, -.4, -.2>, .25, 1 } //親指の上部 pigment { Flesh } } 図 ブロブで作った手 コメントから推測することができるように、我々はここで手を造っている。この画像をレンダリングした後、それに関する僅かな問題があることに気が付く。手のひらと手の後部(ヒール)はもし我々が用いた6個のものの代わりに24個のより小さなコンポーネントを用いて、そして各指を2つのセグメントの代わりに3つのセグメントを用いたならばよりもっとリアリスティックに見えるだろう。でも単純なデモンストレーションのためにこの点は見逃すことにする。しかし、我々が実際にここで言及する必要がある一つのことがある:このかわいそうな仲間は、ひどく痛い腫れた関節を持つように見える! 我々のブロブの知識を復習すると何が間違っていたかを素早く示すことができる。関節はブロブのコンポーネントが重なる場所であり、したがってその点での両コンポーネントの強度の組み合わせはまだ閾値以上にとどまり、表面をさらに外へ広げるようになる。これを直すために我々が必要とするのは、組み合わされたフィールド強度の部分に反対に作用するために負の強度を持つ、重なる領域に対応するコンポーネントである。ブロブに以下のコンポーネントを加える(ファイルblobdem4.pov参照)。 sphere { <-.65,.28,-.05>, .26, -1 } //小指関節のでっぱりに反対に作用 sphere { <-.65,-.28,0>, .26, -1 } //小指の手のひら関節のでっぱりに反対に作用 sphere { <-.3,.44,-.05>, .26, -1 } //薬指関節のでっぱりに反対に作用 sphere { <-.3,-.28,0>, .26, -1 } //薬指の手のひら関節のでっぱりに反対に作用 sphere { <.05,.49,-.05>, .26, -1 } //中指関節のでっぱりに反対に作用 sphere { <.05,-.28,0>, .26, -1 } //中指の手のひら関節のでっぱりに反対に作用 sphere { <.4,.512,-.05>, .26, -1 } //人差し指関節のでっぱりに反対に作用 sphere { <.4,-.4,0>, .26, -1 } //人差し指の手のひら関節のでっぱりに反対に作用 sphere { <.85,-.68,-.05>, .25, -1 } //親指関節のでっぱりに反対に作用 sphere { <.41,-.7,0>, .25, -.89 } //親指の手のひら関節のでっぱりに反対に作用 図 関節が腫れていない手 とってもいいね! 球状コンポーネントの負の強度は近似的にコンポーネントが重なる点のフィールド強度の半分で反対に作用する。それで不格好な非現実的な(そして痛々しく見える)ふくらみがなくされて我々の手の作成は相当に改善された。われわれは多分24個の追加のコンポーネントを用いればまだよりリアルな手を作れるだろうが、今回得た物もかなりの改善である。今回、我々はなめらかな広い配列、流れるような有機的な形を作るためのブロブの力学の十分な基礎知識を得た! 4.4.3 ハイトフィールドオブジェクト ハイトフィールド(height field)はこのためにデザインされたイメージのカラー値あるいはカラーインデックス番号によって決めらた表面を持つオブジェクトである。 ハイトフィールドによって、リアルな山や他の地形が簡単に作れる。最初にハイトフィールドを生成するための画像が必要である。そのようなイメージを作るためにPOV-Rayは理想的である。 image.povという名で新しいファイルを作り以下の内容になるように編集する: #include "colors.inc" global_settings { assumed_gamma 2.2 hf_gray_16 } hf_gray_16 キーワードにより特別な16ビットグレースケール出力となる。これにより完全なハイトフィールドが作れる。通常の8ビット出力ではあまりスムーズではない表面になる。 今度は直接z-軸の下方に原点を指すような位置に置かれたカメラを作る。 camera { location <0, 0, -10> look_at 0 } z=0に壁のように置かれた平面を作る。この平面は完全にスクリーンを満たす。それは白とグレーのしわ(wrinkles)で色づけられる。 plane { z, 10 pigment { wrinkles color_map { [0 0.3*White] [1 White] } } } 最後に光源を作ろう。 light_source { <0, 20, -100> color White } このシーンを 640x480 +A0.1 +FTでレンダリングしよう。あなたは、素晴らしいハイトフィールド(height_field)が生じたイメージを得る。 今度はこのイメージをハイトフィールドを作るために使ってみよう。新しいファイルhfdemo.pov 作って以下のように編集しよう: #include "colors.inc" カメラを原点から2単位上で10単位バックした位置に追加する..。 camera{ location <0, 2, -10> look_at 0 angle 15 } ... また光源は、 light_source{ <1000,1000,-1000> White } ここでハイトフィールドを追加する。 以下の構文の中で Targaイメージファイルが選択され、ハイトフィールドはスムーズで、単純な白のピグメントで、原点のまわりに真ん中になるように移動され、山らしく見えて、スクリーンを満たすようにスケーリングされる。 height_field { tga "image.tga" smooth pigment { White } translate <-.5, -.5, -.5> scale <17, 1.75, 17> } ファイルを保存して、320x240-Aでそれをレンダリングしなさい。ハイトフィールドがあなたの要求を満たす方法として満足が得られたら、より高い解像度でアンチエイリアシング(anti-aliasing)をして再レンダリングしなさい。 図　ハイトフィールドはPOV-Rayで完全に作成できる。 ワオ!ヒマラヤがコンピュータスクリーンに現れた! 4.4.4 レイズオブジェクト 現実の世界では、レイズ(lathe:轆轤(ろくろ)、旋盤)は適当な原材料を回転させ、それが回転するにつれ一部分を彫刻しパターン化された丸い形状を作る工程として参照される。結果は丹念な滑らかに丸くされたエレガントな見かけの、テーブルの足、陶器類、その他のような工芸品になる。POV-Rayでは、レイズ(lathe)オブジェクトは同じ種類の品目を作るために使われるけれども、工程を意味するのではなく、むしろオブジェクトそれ自身を参照する。 ここに本当に基本的なレイズのソースがある(lathdem1.povと呼ぶ。)。 #include "colors.inc" camera { angle 10 location <1, 9, -50> look_at <0, 2, 0> } light_source { <20, 20, -20> color White } lathe { linear_spline 6, <0,0>, <1,1>, <3,2>, <2,3>, <2,4>, <0,4> pigment { Blue } finish { ambient .3 phong .75 } } 図 簡単なレイズオブジェクト。 これをレンダリングして我々が見るものはかなり単純なタイプのレイズであり、子供の帽子(top)のように見える。どのようにこのコードがその効果を生じたか見てみよう。 最初に、6つの点の組が宣言されており、それはレイトレーサーが線分で結ぶ。それらの点を宣言するベクトルにはたった2つの構成要素しかないことに注意しよう。引かれる線分はx-y平面にあるものと仮定される。したがってすべてのz成分はゼロと仮定される。2成分ベクトルの使用は強制的である(3Dベクトルを使用しようとすることはエラーの引き金となる....後にスプラインの解説の中で調査するであろう一つの例外を除いて)。 一度線分が決定されると、レイトレーサーはこの線分をy-軸まわりに回転させ、我々は空間を通してそれが進むような軌跡が残るのを想像することができ、その軌跡の表面がわれわれのオブジェクトになる。 われわれがlinear_splineキーワードを使ったので指定された点は直線で結ばれる。レイズでは他のタイプのスプラインが利用できる。その結果は丸くカーブした点の変化でもなめらかな曲線になるが、しばらくそれを置いておこう。 最初に、我々はちょっとレイズと回転面オブジェクト（SOR）の間の差について話すために本筋を離れたかった。別のチュートリアルで述べたSORオブジェクトは最初の一瞥(glance)ではとてもレイズに類似しているように思われるであろう。それもまた一連の点を宣言し、それらを曲線で結びそれからy-軸まわりに回転させる。レイズは異なる種類のスプライン、線形、2次、3次のようなある種の長所を持つ。そしてもう一つは: SORで用いられる簡単な数学は同じy-座標に戻る曲線を許さない。したがってSORを用いていると曲線が以前にカバーした同じ高さを越えて下がって戻って切断する突然のねじれはエラーを引き起こす。例えば、我々が<0,0>から<2,2>まで弧を描き、それから<4.0>まで下に戻るレイズが欲しかったと仮定する。Y-軸まわりに回転すると、なんだかゼラチン型(gelatin mold)-丸くなった中身のない半トーラスを生ずる。しかし、SORでは曲線がy-方向にそれ自身に再び戻ると、それは違法な宣言となる。 それでもまだ、SORは一つのパワフルな強い点を持つ:それはより単純な順序数学を使うので、一般に同等のレイズより速くレンダリングするのに役立つ。結局それは以下の通りの問題である: その制限が許される物ならSORを使うが、より柔軟な形状が必要ならば代わりにレイズでゆく。 4.4.4.1 スプラインの概念を理解する スプラインを理解するために、もしスプラインのタイプとポイントを操る練習ができその効果がどのような物か見ることができる一種のスプラインワークショップ(作業場)を持てば役に立つだろう。そこで一つ作ってみよう! 今、どのように基本的なレイズを作るかは分かった。それは簡単である(ファイルlathdem2.povを参照): #include "colors.inc" camera { orthographic up <0, 5, 0> right <5, 0, 0> location <2.5, 2.5, -100> look_at <2.5, 2.5, 0> } /* 用いる制御点の設定 */ #declare Red_Point = <1.00, 0.00, 0> #declare Orange_Point = <1.75, 1.00, 0> #declare Yellow_Point = <2.50, 2.00, 0> #declare Green_Point = <2.00, 3.00, 0> #declare Blue_Point = <1.50, 4.00, 0> /* 制御点を見えるようにする */ cylinder { Red_Point, Red_Point - 20*z, .1 pigment { Red } finish { ambient 1 } } cylinder { Orange_Point, Orange_Point - 20*z, .1 pigment { Orange } finish { ambient 1 } } cylinder { Yellow_Point, Yellow_Point - 20*z, .1 pigment { Yellow } finish { ambient 1 } } cylinder { Green_Point, Green_Point - 20*z, .1 pigment { Green } finish { ambient 1 } } cylinder { Blue_Point, Blue_Point- 20*z, .1 pigment { Blue } finish { ambient 1 } } /* 曲線をショーアップするもの */ lathe { linear_spline 5, Red_Point, Orange_Point, Yellow_Point, Green_Point, Blue_Point pigment { White } finish { ambient 1 } } 図　簡単な"スプラインワークショップ"。 今、深呼吸する。すべての外観が少し変だということは分かっている。しかし、単純な説明で簡単にすべてがどうなるか理解することができる。 最初に、われわれは直投影(orthographic)カメラを使っている。もし、それについてまだ読んでいなければ、簡単な要約は: それはシーンをフラットにレンダリングする。透視投影のゆがみが除かれているので側面図ではオブジェクトはグラフ用紙に描かれたようである(モデラーやCADパッケージの側面図のようである)。この実用的な新型カメラにはいくつかの用途がある。しかしここではそれがレイズや円筒の縁を見えるようにする。したがって、我々が見る物はレイズそれ自身よりも、むしろレイズを作る曲線の断面図のようである。その効果を進めるために、ambient 1の仕上げで陰影付けを除く。それはもちろんライティングの必要性もなくす。この特別の側面図を置き、<0,0>がシーンの左下に現れるようにした。 次に、我々は一揃いの点を宣言した。われわれがこれらの点のためにレイズで予期される2Dベクトルの代わりに3Dベクトルを用いたことを注意する。これが我々が初期に言及した例外である。我々が3Dの点を宣言し、それをレイズで使うとき、レイズはベクトルの最初の2成分のみを使う。そして第3の成分が何であろうとも単純に無視される。それがこの例を可能にしているから、ここでそれが扱い易い。 次に、宣言された点について2つのことを行う。第一に、我々はそれらを小さな直径の円筒をカメラに直面している円形の帽子(cap)とともにそれらの点の位置に置く。それから我々はそれらの同じベクトルをレイズを決めるために再使用する。2Dベクトルを宣言する試みは奇妙な結果を得ることになり、実際に我々の円筒の宣言でどうしても必要とする物ではないので、我々は3D座標において単にz-座標をゼロに設定することで第3の成分を無視するというレイズの性癖の利点を採る。 最終結果は:このコードをレンダリングすると、我々が宣言した曲線がどのように見えるかを示す黒い背景の白いレイズ見る。そして円筒の円形の端はx-y平面に沿った我々の制御点がどこにあるかを示す。この場合、とても単純である。線形のスプラインが使われたので我々の曲線は単に直線が点の間をジグザグしている。以下のようにRed_PointとBlue_Pointの宣言を変更する(ファイルlathdem3.pov参照)。 #declare Red_Point = <2.00, 0.00, 0> #declare Blue_Point = <0.00, 4.00, 0> 図 スプラインの点の移動 再レンダリングすると見えるように、起こったことは直線のセグメントがちょうど新しい赤と青い点に適応するように移動するということである。線形スプラインはとてもシンプルなので眠っていても操作できる。違うかい? 何か別のことを試そう。最初に、点を以下のように変更しよう(ファイルlathdem4.pov参照)。 #declare Red_Point = <1.00, 0.00, 0> #declare Orange_Point = <2.00, 1.00, 0> #declare Yellow_Point = <3.50, 2.00, 0> #declare Green_Point = <2.00, 3.00, 0> #declare Blue_Point = <1.50, 4.00, 0> 図 2次スプラインのレイズ レイズの宜言へ戻って、linear_splineをquadratic_splineに変える。再レンダリングして得るものは何だろう?今度は注目に値する物が2つある。第一に、直線の代わりに点を結ぶ滑らかな弧を得る。これらの弧は2次曲線で作られているので、我々の今度のレイズはより興味深い。また、Red_Pointはもはや曲線に接続されない。何が起こったか? そう、任意の2点で直線は決定されるが、2次曲線を決めるには3点が必要である。POV-Rayは結ぶために2点だけを見るわけではなく、それらを結ぶために用いられる2次曲線の式を決めるためにそれらに先行する点を直接参照する。曲線の始点で問題が生ずる。曲線の最初の点以前には点がない。だから一つを宣言する必要がある。したがって2次スプラインを用いるとき、指定する最初の点はそこにあるだけであり、POV-Rayがどんな曲線が最初の2点を結ぶかを決めることができるということを覚えていなければならない。それは実際の曲線の一部分としては示されない。 このレイズの例に関してもう一つのことがある。我々の曲線は滑らかにカーブした線でつながれたけれども、それらの曲線間の変化は...さて、波立っているみたいだ。ちがう?この曲線は個々の点の間のそれぞれの曲線がひどくミスマッチなように見える。何を作ろうとしているかによって、これは受け入れられるかもしれないし、もっと滑らかな曲線形状が望まれるかも知れない。もし後者であれば、幸いに、他のオプションがある。 2次スプラインは線形スプラインに比べてレンダリングに長い時間がかかる。数学がより複雑になる。でもまだ形状を本当に滑らかにするために、そうするための唯一の方法である三次スプラインが切望される。我々の例に戻ろう。そして単純にquadratic_splineをcubic_splineで置き換えよう(ファイルlathdem5.pov参照)。もう一度レンダリングしてどうなるか見てみよう。 図 三次スプラインレイズ。 2次スプラインは曲線を決めるために3点をとったけれども、3次では4点が必要である。だから、我々が予期したように、Blue_Pointは今度は曲線から外れる、ちょうどRed_Pointがそうだったように、我々の曲線の最初と最後の点は残りの点の間の曲線の形状を定めるためだけの制御点としてだけのものとなる。しかしOrange_PointからYellow_Pointへ、そしてGreen_Pointへ戻る点の変化を見てみよう。今度はミスマッチに見えずにわれわれの曲線は滑らかに結合された曲線のように見える。 スプラインのコンセプトは手頃で必要な物である。これはプリズム及びポリゴンオブジェクトで再び見られる。しかし、少しいじくり回すことで、我々はそれらで作業する感触をすぐに獲得することができる。 4.4.5 メッシュオブジェクト メッシュ(Mesh)オブジェクトは、それによって何百あるいは何千もの三角形を含むオブジェクトを作ることができるため非常に役に立つ。三角形の単純な結合(union)と比較すると、メッシュオブジェクトではより効率的に三角形の情報を蓄えることができる。メッシュオブジェクトの複写では三角形は一度保存されるだけなので、わずかな必要メモリの追加だけでよい。 ほとんどすべてのオブジェクトは三角形を用いて近似できるが複雑な形状を作るにはたくさんの三角形を必要とする。そこで、非常に単純なメッシュの例だけを示す。この例では非常に便利な三角形メッシュの機能-それぞれの三角形に異なるテクスチャを割り当てられる-を示す。 さて、始めよう。別々の単純な色の付いた面を持つボックスを作る。meshdemo.povという名の空きファイルを作成し、次の行を加えなさい。 camera { location <20, 20, -50> look_at <0, 5, 0> } light_source { <50, 50, -50> color rgb<1, 1, 1> } #declare Red = texture { pigment { color rgb<0.8, 0.2, 0.2> } finish { ambient 0.2 diffuse 0.5 } } #declare Green = texture { pigment { color rgb<0.2, 0.8, 0.2> } finish { ambient 0.2 diffuse 0.5 } } #declare Blue = texture { pigment { color rgb<0.2, 0.2, 0.8> } finish { ambient 0.2 diffuse 0.5 } } メッシュ内で使いたいテクスチャはメッシュが作成される前に宣言しなければならない。テクスチャはメッシュの内部ではメモリパフォーマンスが悪くなるため指定することができない。 メッシュオブジェクトを加えよう。ボックスの3つの側面は別々のテクスチャが使われる。他の側面はグローバルなテクスチャが使われる。 mesh { /* 上面 */ triangle { <-10, 10, -10>, <10, 10, -10>, <10, 10, 10> texture { Red } } triangle { <-10, 10, -10>, <-10, 10, 10>, <10, 10, 10> texture { Red } } /* 底面 */ triangle { <-10, -10, -10>, <10, -10, -10>, <10, -10, 10> } triangle { <-10, -10, -10>, <-10, -10, 10>, <10, -10, 10> } /* 左側面 */ triangle { <-10, -10, -10>, <-10, -10, 10>, <-10, 10, 10> } triangle { <-10, -10, -10>, <-10, 10, -10>, <-10, 10, 10> } /* 右側面 */ triangle { <10, -10, -10>, <10, -10, 10>, <10, 10, 10> texture { Green } } triangle { <10, -10, -10>, <10, 10, -10>, <10, 10, 10> texture { Green } } /* 前面 */ triangle { <-10, -10, -10>, <10, -10, -10>, <-10, 10, -10> texture { Blue } } triangle { <-10, 10, -10>, <10, 10, -10>, <10, -10, -10> texture { Blue } } /* 後面 */ triangle { <-10, -10, 10>, <10, -10, 10>, <-10, 10, 10> } triangle { <-10, 10, 10>, <10, 10, 10>, <10, -10, 10> } texture { pigment { color rgb<0.9, 0.9, 0.9> } finish { ambient 0.2 diffuse 0.7 } } } このシーンを320x240でトレースしなさい。ボックスの上、右および前面が異なるテクスチャであるのが分かるでしょう。これはそれほど感動的な例ではないが、あなたにメッシュオブジェクトを使って何ができるかは理解してもらえるだろう。スムーズ三角形も使ったもっと複雑な例はsceneディレクトリの下にchesmsh.pov とrobotmsh.povにある。 4.4.6 ポリゴンオブジェクト ポリゴン(Polygon:多角形)オブジェクトは正方形、矩形、五角形、六角形、八角形など各種の平面n辺形を作成するために用いることができる。 一つのポリゴンはその形を記述するたくさんの点によって定義される。ポリゴンは閉じていなければならないため最初の点が点列の最後に繰り返されなければならない。 以下の例では POVという文字をたった一つの polygon文で定義する。 望む形を記述するために必要な点を考えることから始めよう。求めるものは文字Oが中央にあるx-y平面上の文字列とする。文字列は y=0 から y=1までの範囲とする。したがってそれぞれの点は次のようになる( z 座標は自動的に0にセットされる)。 Letter P (outer polygon): <-0.8, 0.0>, <-0.8, 1.0>, <-0.3, 1.0>, <-0.3, 0.5>, <-0.7, 0.5>, <-0.7, 0.0> Letter P (inner polygon): <-0.7, 0.6>, <-0.7, 0.9>, <-0.4, 0.9>, <-0.4, 0.6> Letter O (outer polygon): <-0.25, 0.0>, <-0.25, 1.0>, < 0.25, 1.0>, < 0.25, 0.0> Letter O (inner polygon): <-0.15, 0.1>, <-0.15, 0.9>, < 0.15, 0.9>, < 0.15, 0.1> Letter V: <0.45, 0.0>, <0.30, 1.0>, <0.40, 1.0>, <0.55, 0.1>, <0.70, 1.0>, <0.80, 1.0>, <0.65, 0.0> 文字 P と O 両者には穴があり、Vは一つのポリゴンからなる。他の2つの文字より定義が簡単なので文字 V から始める。 新しいファイル polygdem.pov を作って以下のテキストを加えなさい。 camera { orthographic location <0, 0, -10> right 1.3 * 4/3 * x up 1.3 * y look_at <0, 0.5, 0> } light_source { <25, 25, -100> color rgb 1 } polygon { 8, <0.45, 0.0>, <0.30, 1.0>, // 文字 "V" <0.40, 1.0>, <0.55, 0.1>, <0.70, 1.0>, <0.80, 1.0>, <0.65, 0.0>, <0.45, 0.0> pigment { color rgb <1, 0, 0> } } 先に注意したようにポリゴンは点列の最後に最初の点を加えることによって閉じたものとしなければならない。閉じたポリゴンは常に最後の位置が最初の点と同じ点列で定義される。 文字 Vを作成した後、続いて文字 Pを作る。Pには穴があるから基本形から穴を切り抜く方法を見つけなければならない。それは非常に簡単である。まず閉じたポリゴンでPの外形を定義し、穴の形を記述する点列をそれに加える。これもまた閉じたポリゴンである。これがしなければならないことのすべてである。両ポリゴンが重なる部分に穴ができる。 一般に一つのpolygon文内の偶数のサブポリゴンが重なる場合は常に穴ができる。サブポリゴンは閉じた点列で定義される。 文字 P は2つのサブポリゴンを含む。一つは外形のためで、もう一つは穴である。穴のポリゴンと外形のポリゴンが重なるため穴ができる。 一つのpolygon文の中に複数のサブポリゴンがある場合どのように作用するかが理解できれば、残りの文字Oを加えることはとても簡単である。 最後に完全な単語 POVを得る。 polygon { 30, <-0.8, 0.0>, <-0.8, 1.0>, // 文字 "P" <-0.3, 1.0>, <-0.3, 0.5>, // 外形 <-0.7, 0.5>, <-0.7, 0.0>, <-0.8, 0.0>, <-0.7, 0.6>, <-0.7, 0.9>, // 穴 <-0.4, 0.9>, <-0.4, 0.6>, <-0.7, 0.6> <-0.25, 0.0>, <-0.25, 1.0>, // 文字 "O" < 0.25, 1.0>, < 0.25, 0.0>, // 外形 <-0.25, 0.0>, <-0.15, 0.1>, <-0.15, 0.9>, // 穴 < 0.15, 0.9>, < 0.15, 0.1>, <-0.15, 0.1>, <0.45, 0.0>, <0.30, 1.0>, // 文字 "V" <0.40, 1.0>, <0.55, 0.1>, <0.70, 1.0>, <0.80, 1.0>, <0.65, 0.0>, <0.45, 0.0> pigment { color rgb <1, 0, 0> } } 図 一つのポリゴン構文で作成された単語"POV" 4.4.7 プリズム/多角柱(Prism)オブジェクト プリズムは本質的には直線の経路に沿ってスウィープ(掃引)されるポリゴンあるいは閉曲線である。この形は空間に軌跡を残すスウィープとして想像することができる。そして軌跡の表面がわれわれのプリズムの表面となる。プリズムの表面を形作る曲線やポリゴンは任意の数の副次的な形(sub-shapes)の複合にでき、3種類のスプラインの任意の種類が使え、またスウィープされるように一定の幅を保つか、徐々に一端の細い点に向かって先細りにすることができる。しかしこれがあまりに混乱させるようになる前に、最も単純な形状のプリズムで一度に1ステップから始めよう。以下のPOVコードを入力しレンダリングしよう(ファイルprismdm1.pov参照)。 #include "colors.inc" camera { angle 20 location <2, 10, -30> look_at <0, 1, 0> } light_source { <20, 20, -20> color White } prism { linear_sweep linear_spline 0, // ここから以下の形状を掃引(スウィープ)する... 1, // ... ここまで 7, // 形状を形作る点の数 ... <3,5>, <-3,5>, <-5,0>, <-3,-5>, <3, -5>, <5,0>, <3,5> pigment { Green } } 図 六角形のプリズム形状。 これは六角形のポリゴンを作り、それはy=0からy=1までスウィープされる。言い換えると、押し出された六角形が得られる。注意すべき一つの点は、これは6辺形状であるが、われわれは合計7つの点を用いたことである。これはそのポリゴンが閉じた形と仮定され、最後の点を最初の点と同じにするからである。技術的には、直線のポリゴンでは、これをしないと警告が発せられるが、POV-Rayはこれを閉じるために自動的に2つの端を結合する。しかしこれは線形のスプラインだけに作用するので、これらの警告メッセージに対してあまり無頓着ではいけない。 4.4.7.1 古いスプラインの新しい秘訣を教える レイズのチュートリアル(セクション「スプラインのコンセプトを理解する」)でカバーされるスプラインに関するセクションをフォローすると、線形の他に2つの付加的な種類のスプラインがあることを知る:2次と3次スプラインである。もちろん、我々はこれらをより自由な形状を作成するためにプリズム、なめらかにカーブしたタイプのプリズムで使うことができる。 一つの止め金(catch)があり、レンダリングからプリズムを守るために、「プリズムの点が少なすぎる」という奇妙なメッセージから我々の髪が引き裂かれることを守るためにわれわれはこのセクションを注意深く読まなければならない。多分、我々はこれが頭部のところであると推測することができるだろう:どのように線形でないスプラインは閉じるのか。もしわれわれが最後の点を最初の点と同じにするのを忘れても最後の点と最初の点を単純につないでくれる線形スプラインとちがって、2次と3次のスプラインはちょっぴり曖昧である。 まず最初に、2次スプラインは任意の2点を結ぶ際にその2点と直前の点をもとに曲線の式を決めるということを思い出そう。したがって2次スプラインの最初の点はただの制御点であり、実際の曲線の一部分にはならない。これが意味するところは:2次スプラインで形状を作る場合、2番目の点を最後の点に一致させなければならない。なぜならば最初の点は曲線上になく、計算上の目的のために必要な単なる制御点だからである。 同様に、3次スプラインは最初の点と最後の点の両方が制御点であることを必要とする。したがって、3次スプラインで作られた形状を閉じるためには、2番目の点と最後から2番目の点を一致させなければならない。2次あるいは3次スプラインで正しい点を一致させないと、その場合、プリズムに点が少なすぎる(too few points in prism)というエラーが出る。POV-Rayはわれわれが形状を閉じるのを待っていて、そして閉じるのを見ずに点を走り抜けたときエラーが出される。 混乱したかい? OK、例はどうだろう? われわれのプリズムほんの一部をこれで置き換えよう(ファイルprismdm2.pov参照)。 prism { cubic_spline 0, // ここから以下の形状を掃引(スウィープ)する... 1, // ... ここまで 6, // 形状を形作る点の数 ... < 3, -5>, // point#1 (制御点 ... 曲線上にない) < 3, 5>, // point#2 ... この点は ... <-5, 0>, // point#3 < 3, -5>, // point#4 < 3, 5>, // point#5 ... この点と一致しなければならない <-5, 0> // point#6 (制御点 ... 曲線上にない) pigment { Green } } 図 三次の、三角形状のプリズム形。 この単純なプリズムが、その角を紙やすりでなめらかに磨かれた、押し出された三角形のように見えるものを生じる。点2、3および4は三角形の角である、そして、点5は点2の場所に戻ることによって形を閉じる。点1と6において、それらは制御点であり、他の点との間でどんな曲線が使われるかを計算する手助けをする。 4.4.7.2 なめらかな変化 ノートすべき便利なことは、われわれが点1を点4に等しくし、また点6を点3と等しくしたことである。そう、これは重要である。もし制御点がわれわれがしたようなものでないと、このプリズムはまだ正常に閉じるだろうけれども、その曲線の点の間の変化は滑らかではなくなるだろう。点1と6を<4,6> と <0,7>にそれぞれ変更し、再レンダリングして後ろのへりがどのように変化するかを見よう(ファイルprismdm3.pov参照)。 これをより一般的にすると、もしわれわれが3次スプラインにおいて滑らかな閉じ方を望むならば、最初の制御点を最後の点から3番目の点に等しくするのである。2次スプラインにおいては、この秘訣は同じであるが、最初の点だけが制御点であるのでそれを最後から2番目の点と等しくする。 4.4.7.3 複数の副次形状(sub-shapes) ちょうどポリゴンオブジェクトと同様に(セクション「ポリゴンオブジェクト」参照)プリズムはとても柔軟であり、サブ・プリズムから一つのプリズムを作ることが可能である。これを行うには、しなければならないことは、すでに閉じた最初の形状の後に点のリスティング(並び)を続けることである。2番目の形状は、最初の形状から別の方向へ行くように加えられるが、より面白いことの一つは、もし任意の偶数個の形状が重なると、それらが重なった領域は、あたかも両副次形状(sub-shape)から切り取られたように作用することである。 別の例を見よう。もう一度、前と同じようにカメラ、ライトその他が基本的なコードで、しかしこの複雑なプリズムを代用しよう(ファイルprismdm4.pov参照)。 prism { linear_sweep cubic_spline 0, // ここから以下の形状を掃引(スウィープ)する... 1, // ... ここまで 18, // 形状を形作る点の数 ... <3,-5>, <3,5>, <-5,0>, <3, -5>, <3,5>, <-5,0>, // sub-shape #1 <2,-4>, <2,4>, <-4,0>, <2,-4>, <2,4>, <-4,0>, // sub-shape #2 <1,-3>, <1,3>, <-3,0>, <1, -3>, <1,3>, <-3,0> // sub-shape #3 pigment { Green } } 図 より複雑な形状を作成するために副次形状を用いる。 読み安さのために、新しい副次形状に移動する度にわれわれは毎回新しい行を開始したが、レイトレーサーはもちろん、(初期に述べたように)形状が閉じられるかどうかに基づいて、それぞれの形状がどこで終わるかがわかる。この新しいプリズムをレンダリングして何が得られるかを見よう。それはお馴染みの同じ形状であるが、今度は小さい版の形状が中心から彫刻され、その彫られた部分はいくぶん小さく紙やすりでみがかれ穴に戻されたように見える。 単純に外側のへりは副次形状1だけが存在する場所であり、彫られた部分は副次形状1と2が重なり合う場所である。極端な中心部では、副次形状1、2および3が互いに重なるので再び奇数の小片が重なるのでオブジェクトが再び現れる。このテクニックを使って任意の数の極めて複雑なプリズムを作ることができる! 4.4.7.4 円錐スウィープと先細り効果 われわれのオリジナルのプリズムにおいては、キーワードlinear_sweepは実際に任意であった。これはスウィープのタイプが指定されないときのプリズムで仮定されるデフォルトのスウィープである。しかし、別の極めて便利な種類のスウィープがある:円錐スウィープ(conic sweep)である。形状を最初の高さから二番目の高さまでスウィープする間、一点から2番目の点まで一定にそれを広げ、われわれがそれを作り始める原点に対してその形状が広げられることを除き、基本的なアイディアはオリジナルのプリズムと似ている。そのような効果の何が良いかのちょっとしたアイディアを示すために、現在あるプリズムをこれで置き換えよう(ファイルprismdm5.pov参照): prism { conic_sweep linear_spline 0, // 高さ 1 1, // 高さ 2 5, // 形状を作成するための点の数... <4,4>,<-4,4>,<-4,-4>,<4,-4>,<4,4> rotate <180, 0, 0> translate <0, 1, 0> scale <1, 4, 1> pigment { gradient y scale .2 } } 図 円錐状スウィーピングを用いたピラミッドの作成 われわれのオブジェクトに現在のライトとカメラ角度を正しく固定しなければならないことなく定義を与えるためにgradientピグメントが選択された。しかし、それをレンダリングして我々は何を作ったのだろう?水平な縞模様のピラミッドだ!四角形の4点を結んでいる線形スプラインとスプラインを閉じるためにあるお馴染みの最後の点を認めることができる。 オブジェクトの宣言の中のすべての変換に注意しなさい。少し説明するところである。回転(rotate)と平行移動(translate)は簡単である。通常、円錐状スウィープは頂上で完全なサイズで始まり、y=0の点まで先細りになるが、もちろんピラミッドを作っているときはさかさまになる。したがって、上を正しく置くように形状をx-軸まわりにフリップし、実際にその点まわりに旋回したので、われわれが始めたときの位置にそれを戻すために平行移動する。 拡大(scale)はこの例の寸法を正しくするために置かれた。ベースは8単位×8単位であるが、高さは(y=1からy=0)のたった1単位であるので、外側に少し伸ばしたのである。この点について、多分「なぜ、ちょうどy=0からy=4までスウィープしこの全体のスケーリングを避けないのか?」と思うだろう。 それは円錐スウィープの非常に重要なgotcha※である!(※訳注:意味不明) それの何が間違っているかを理解するために、それを実際に試してみよう(ファイルprismdm6.pov参照)。scale構文を取り除くのを確認し、 1, // 高さ 2 に読める行を 4, // 高さ 2 で置き換えなさい。(訳注:オリジナルの1を4にした。) これはy=4で2番目の高さを設定するので、再レンダリングしてその効果が同じかどうかを見よう。 図 円錐スウィープに対して2番目の高さを1より大きく選ぶ。 ワア!我々の高さは正しいが、ピラミッドのベースが巨大になった!なにが間違いだったのか? 簡単である。ベースは、たとえ2番目の高さに何を設定してもy=1で我々が用いた点が記述したとおりに実際に起こるのである。しかし、もしわれわれが2番目の高さを1より高く設定すると、一度スウィープがy=1を通過すると、オリジナルのベースの後に続くように同じ線に沿って外に広げられることが続けられ、実際のベースが進むにつれ大きく大きくなる。 円錐スウィーププリズムのコントロールを失わないためには、たいてい2番目の高さをy=1にとどめておき、その単位サイズから高さを調整するためにscale構文を使うのがベストである。このように、われわれは常にベースの角が思うとおりの場所に残っていることを確認することができる。 それは円錐スウィープに関するもう一つの興味深いことに導く。何かの理由でもしある点までずうっと先細りにしたくはないときはどう?もし完全なピラミッドの変わりにもっとジグラット(階段状ピラミッド)のような段が欲しい場合はどう? 簡単にできる。2番目の高さを1に戻して、scale文を置き換えた後、 0, // height 1 と読める行を 0.2, // height 1 に変更する。(訳注:オリジナルの0を0.2にした。) 図 円錐スウィープで最初の高さを増やす。 再レンダリングすると、スウィープがずっとその点まで行くのを短く止め、頂上のないピラミッドを与えるのを見る。正確にどれくらい頂上が切り取られるかは最初の高さが2番目の高さにどれくらい接近しているかに依存する。 4.4.8 超2次楕円体オブジェクト ときとしてボックスのような完全に鋭いエッジを持たないオブジェクトを作りたくなる。そんな時、超2次楕円体(Superquadric Ellipsoid)がその役に立つオブジェクトである。これは単純な構文で記述される: superellipsoid { } ここで r と n は float型の変数で、0より大きく1以下である。超楕円体(superellipsoid)を作ってrとnの値によってどんな種類の形状が作れるか実験してみよう。 ファイルsupellps.pov と作って以下のように編集しよう: #include "colors.inc" camera { location <10, 5, -20> look_at 0 angle 15 } background { color rgb <.5,.5,.5> } light_source { <10, 50, -100> White } グレイの背景を加えるとオブジェクトが分かり安い。 さらに、以下のようにタイプしよう: superellipsoid { <.25,.25> pigment { Red } } ファイルを保存し、形を見るために 200x150 -A でトレースしよう。これはボックスのように見えるでしょう。でもエッジは丸くなっている。では、別のrとnの値で実験してみよう。今度のトレースでは、<1, 0.2>を試してみよう。今度の形は円筒のように見えるけど、上のエッジが丸くなっているでしょう。今度は <0.1, 1>。この形は奇妙な形でなんて呼んだらいいのか分からないけど、おもしろいね。最後に<1, 1>をやってみよう。これはよく知ってるね...球だ! あなたが超楕円体について知っていなければならないことが2つある。第一に、あなたはrにもnにも0の値を使ってはならない。それによって、あなたの要求する形の代わりにPOV-Rayが間違ってブラックボックスを作るようになる。二番目に、rとnの非常に小さい値は妙な結果を生むかもしれないので、それらは避けられなければならない。最後に、ステュルムの求根法(Sturmian root solver)※は超楕円体に対してはうまく働かない。 超楕円体は有限オブジェクトであるので自動バウンディング(自動境界付け)に応答し、またCSGでも使える(4.5節参照)。 (※訳注:ステュルム(Sturm)の定理により代数方程式を解く方法) 今度は何かシーンに役立つ物を作るために超楕円体を使おう。我々は、タイルを張られた床を作って、それの上に浮かんでいる二つの超楕円体オブジェクトを置く。先に作ったファイルから出発しよう。 ファイル名をtiles.povに変更し、以下のように編集しよう: #include "colors.inc" #include "textures.inc" camera { location <10, 5, -20> look_at 0 angle 15 } background { color rgb <.5,.5,.5> } light_source{ <10, 50, -100> White } 注意: #include "textures.inc" を追加した。こうすると前もって定義されたテクスチャが使える。われわれのタイルになる超楕円体を定義したい。 #declare Tile = superellipsoid { <0.5, 0.1> scale <1,.05, 1> } 超楕円体はあなたが他でスケール変換しなければだいたい 2*2*2 単位である。 われわれがタイルの集まりを並べて置きたいのならば、それらは重ならないために互いにオフセットを持たなければならない。オフセット値はタイルの間のいくらかの空間をセメントの目地で満たさなければならないため2よりほんの少し大きい値を選ばなければならない。そこでこれを加えよう: #declare Offset = 2.1 今、一列のタイルを置きたい。各タイルはオリジナルから連続して増加する量によって+zと-z方向にオフセットされる。その列内の個々のタイルの位置を決定するためにオフセットを参照しタイルの順序を掛ける。さらにこれらのタイルをRowという名の一つのオブジェクトに以下のように結合する: #declare Row = union { object { Tile } object { Tile translate z*Offset } object { Tile translate z*Offset*2 } object { Tile translate z*Offset*3 } object { Tile translate z*Offset*4 } object { Tile translate z*Offset*5 } object { Tile translate z*Offset*6 } object { Tile translate z*Offset*7 } object { Tile translate z*Offset*8 } object { Tile translate z*Offset*9 } object { Tile translate z*Offset*10 } object { Tile translate -z*Offset } object { Tile translate -z*Offset*2 } object { Tile translate -z*Offset*3 } object { Tile translate -z*Offset*4 } object { Tile translate -z*Offset*5 } object { Tile translate -z*Offset*6 } } これは一行の17枚のタイルになり、スクリーンを満たすのに十分である。POV-Ray 3.0にはこのような多くの反復するオブジェクトに対するより良い手段があるが、ここでは使わない。ここでは同じ方法で再びオフセット値を用いた増加量によって、+x方向と-x方向両方に列のコピーを作って、それを移動しなければならない。 object { Row } object { Row translate x*Offset } object { Row translate x*Offset*2 } object { Row translate x*Offset*3 } object { Row translate x*Offset*4 } object { Row translate x*Offset*5 } object { Row translate x*Offset*6 } object { Row translate x*Offset*7 } object { Row translate -x*Offset } object { Row translate -x*Offset*2 } object { Row translate -x*Offset*3 } object { Row translate -x*Offset*4 } object { Row translate -x*Offset*5 } object { Row translate -x*Offset*6 } object { Row translate -x*Offset*7 } これで我々のタイルは完成である。しかしそれらにテクスチャが必要である。そのためにタイルのすべての行を結合して白い大理石(White_Marble)のピグメントといくぶん光る反射表面を施す: union{ object { Row } object { Row translate x*Offset } object { Row translate x*Offset*2 } object { Row translate x*Offset*3 } object { Row translate x*Offset*4 } object { Row translate x*Offset*5 } object { Row translate x*Offset*6 } object { Row translate x*Offset*7 } object { Row translate -x*Offset } object { Row translate -x*Offset*2 } object { Row translate -x*Offset*3 } object { Row translate -x*Offset*4 } object { Row translate -x*Offset*5 } object { Row translate -x*Offset*6 } object { Row translate -x*Offset*7 } pigment { White_Marble } finish { phong 1 phong_size 50 reflection.35 } } 我々は漆喰(grout)を追加する必要がある。これは簡単に白い平面で可能である。ここでambient(環境光)を少しステップアップしたのでより白く見える。 plane { y, 0 //これは漆喰 pigment { color White } finish { ambient.4 diffuse.7 } } 我々のシーンを完了するために、各々異なる色の、5つの異なる超楕円体がタイルの上に浮かんで、タイルがそれらに映るように加えよう。 superellipsoid { <0.1, 1> pigment { Red } translate <5, 3, 0> scale.45 } superellipsoid { <1, 0.25> pigment { Blue } translate <-5, 3, 0> scale.45 } superellipsoid { <0.2, 0.6> pigment { Green } translate <0, 3, 5> scale.45 } superellipsoid { <0.25, 0.25> pigment { Yellow } translate <0, 3, -5> scale.45 } superellipsoid { <1, 1> pigment { Pink } translate y*3 scale.45 } 図　超楕円体(superellipsoids)がタイルの上に浮かぶ。 結果を見るために 320x200 -Aでシーンをトレースしよう。ハッピーになったら最後に 640x480 +A0.2でトレースしよう。 4.4.9 回転面オブジェクト 瓶や花瓶、グラスはレイトレーシングにおいて素晴らしいオブジェクトである。われわれは金のカップを回転面(Surface of Revolution)オブジェクト(SOR オブジェクトを)使って作りたい。 最初に最終オブジェクトの形状を考えることから始める。POVの回転面オブジェクトをサポートするモデリングプログラムの援助なしで、与えられたカーブを記述する一揃いの点を考えつくのはとても難しい。そのようなプログラムが利用できるならば、あなたはその利点をいかすべきである。 図　カップオブジェクトの点の構成 われわれは上図で示された点構成を使う。カップを得るためにy-軸について回転されるカーブを記述するための8つの点がある。カーブはリファレンスセクションで述べる方法によって計算される、(「回転面」を参照 )。 上記のSORオブジェクトを使ったシーン考えよう。sordemo.pov という名のファイルを編集し、次のテキストを打ち込もう。 #include "colors.inc" #include "golds.inc" global_settings { assumed_gamma 2.2 } camera { location <10, 15, -20> look_at <0, 5, 0> angle 45 } background { color rgb<0.2, 0.4, 0.8> } light_source { <100, 100, -100> color rgb 1 } plane { y, 0 pigment { checker color Red, color Green scale 10 } } sor { 8, <0.0, -0.5>, <3.0, 0.0>, <1.0, 0.2>, <0.5, 0.4>, <0.5, 4.0>, <1.0, 5.0>, <3.0, 10.0>, <4.0, 11.0> texture { T_Gold_1B } } このシーンには、チェック模様の平面に載った我々のカップオブジェクトがある。これを 320x200 の解像度でトレースすると下図のようになる。 図　回転面(surface of revolution)オブジェクト。 回転面(surface of revolution)の定義は点の数で始まり、高さが増える順の点列によって記述される。各点が与えられた高さでのカーブの半径を与える。たとえば最初の点は高さ -0.5 で半径 0であるとPOV-Rayに教える。各点は前の点よりもより高い点になるように注意しなければならない。そうでないとプログラムはエラーメッセージとともに中断する。 4.4.10 テキストオブジェクト POV-Rayを使ってテキスト(Text)オブジェクトを作るということは文字列を骨の折れるプロセスのCGSで作るか、あるいは白と黒のイメージを使ったいくぶん満足な ハイトフィールドを使うことを意味していた。今、POV-Ray 3.0のためにテキストオブジェクトを作るためにTrueTypeフォントを使うことができる新しいプリミティブが導入された。これらのオブジェクトは、他のPOVプリミティブのようにCSGの中で使うことができるし、変形することができるし、テクスチャもつけられる。 このチュートリアルのために、我々はテキストオブジェクトの2つの利用法を用意する。最初にチェッカー平面上に載ったブロック文字を作る。すべての TTFフォントが使えるはずである※がここではPOV-Ray3.0に同梱されているものを使う。 (※訳注:オリジナルでは日本語2バイトフォントは不可。パッチが公開されている。) ファイルtextdemo.povを作り以下のように編集: #include "colors.inc" camera { location <0, 1, -10> look_at 0 angle 36 } light_source { <500,500,-1000> White } plane { y,0 pigment { checker Green White } } 次にテキストオブジェクトを加えよう。我々はフォントtimrom.ttfを使う。そして、文字列"POV-Ray 3.0"を作る。今は、赤い文字を作るだけにしよう。構文は非常に単純である。引用符の中の最初の文字列はフォント名であり、二番目はレンダリングする文字列である。2つの浮動小数点数値(float)は、厚さとオフセット値である。厚さはブロック文字の厚さを決める。それには大抵0.5から2の値が適当である。オフセット値は、文字のカーニング間隔に加えられる。ここでは0のままにしておく。 text { ttf "timrom.ttf" "POV-RAY 3.0" 1, 0 pigment { Red } } これを200x150 -Aでレンダリングすると、文字が画面の右側に離れているのに気がつくだろう。これは最初の文字の左下手前の角が原点に置かれているためである。文字列を中心に置くためには-x方向にいくらかの距離を移動する必要がある。しかしどのくらいだろう。ドキュメントを見ると、文字がすべて 0.5 から 0.75 単位の高さであるということが見つかる。各文字が、x軸方向のスペースをだいたい0.5単位とると仮定すると文字列の長さは12文字とスペースでだいたい6単位になることを意味する。文字列をx軸の負の方向に3単位移動しよう。 text { ttf "timrom.ttf" "POV-Ray 3.0" 1, 0 pigment { Red } translate -3*x } 良くなった。テキストオブジェクトのいくつかのパラメータで遊んでみよう。最初にthicknessの浮動小数点数値を飛ばして増やしてみよう... 25だ! text { ttf "timrom.ttf" "POV-Ray 3.0" 25, 0 pigment { Red } translate -2.25*x } 実際に、これはクールの類である。今度はthicknessの値を1に戻してoffset値を 0から0.1に変えて再レンダリングしよう。 ちょっと待って?! 文字列は離れて上へ曲がりくねる。これはドキュメントには書いてない!オフセット値はわれわれがそういう目的を持ったかのようにx軸だけでなくxとy軸両方に適用されるようだ。ここに浮動小数点数(float)の代わりにベクトルを呼び出せないのか？やってみよう。0.1を0.1*xで置き換えて再描画してみよう。オフセットの浮動小数点数値を0から0.1に変えて再描画してみよう。 それはうまくゆく。文字列はまだx軸に沿って直線を保ったままで，さらに少し離れる。y軸だけのオフセットを試してこれを確認しよう。0.1*x を 0.1*yで置き換えよう。またしてもこれは期待どうりうまくいく。文字列はx軸に沿って加えられた付加距離なしで右側に一定角度で上がってゆく。今度はz軸で試そう。0.1*yを0.1*zで置き換えよう。これを表現することは失望を生む。オフセットは起こらない！オフセット値は、xとy方向に適用できるだけである。 ブロック式字体に、より装飾的なテクスチャを与え、そのクールな大きいthickness値を使って、わずかなyオフセットを加えることによって我々のシーンを終えよう。楽しみのために、天球に投げ入れ、平面をちょっとダンディーにして、もう少しおもしろいカメラ位置を使おう(以下のシーンを640x480 +A0.2で描画してみなさい) #include "colors.inc" camera { location <-5,.15,-2> look_at <.3,.2,1> angle 36 } light_source { <500,500,-1000> White } plane { y,0 texture { pigment { SeaGreen } finish { reflection.35 specular 1 } normal { ripples.35 turbulence.5 scale.25 } } } text { ttf "timrom.ttf" "POV-RAY 3.0" 25, 0.1*y pigment { BrightGold } finish { reflection.25 specular 1 } translate -3*x } #include "skies.inc" sky_sphere { S_Cloud5 } 今度はテキストをCSGオブジェクトで使おう。テキストオブジェクトを使った石のブロックにはめ込み細工(inlay)を作ってみよう。新しいファイルtextcsg.povを作成して、次のようにそれを編集する: #include "colors.inc" #include "stones.inc" background { color rgb 1 } camera { location <-3, 5, -15> look_at 0 angle 25 } light_source { <500,500,-1000> White } ブロックを作ろう。われわれのテキスト文字列( POV-RAY 3.0 )が6単位の長さであるから，それは約8単位幅である。また高さは4単位、奥行きは1単位とする。テキストオブジェクトと位置の等しい表面をさける必要があるので、最初のz座標を0の代わりに1にする。最後にこのブロックにすてきな石のテクスチャを与える。 box { <-3.5, -1, 0.1>, <3.5, 1, 1> texture { T_Stone10 } } 次にテキストオブジェクトを作りたい。われわれは厚さとオフセットを少し変えるだけで最初のチュートリアルで使ったのと同じオブジェクトを使える。 text { ttf "timrom.ttf" "POV-Ray 3.0" 0.15, 0 pigment { BrightGold } finish { reflection.25 specular 1 } translate -3*x } テキストオブジェクトがデフォルトでその正面の表面が直接x-y平面に横たわるように置かれるのを思い出そう。ボックスの正面がz=0.1から始まり、そして、厚さが0.15の値をつけられるならば、「はめ込み細工」の深さは、0.05単位である。先に進んで二つのオブジェクトの周りに別のブロックを置いてみよう。 difference { box { <-3.5, -1, 0.1>, <3.5, 1, 1> texture { T_Stone10 } } text { ttf "timrom.ttf" "POV-Ray 3.0" 0.15, 0 pigment { BrightGold } finish { reflection.25 specular 1 } translate -3*x } } 図　石から切り出されたテキスト。 これを200x150 -Aで描画しよう。はっきりとはめ込み細工(inlay)が見える。それは本当に明るい金色である。結果をもっとはっきりと見るために 640x480 +A0.2 で描画しよう。前もって注意するが...このトレースはちょっと時間がかかるよ。 4.4.11 トーラスオブジェクト トーラス(Torus:輪環面)はドーナッツあるいはインナーチューブ(innertube)と考えることができる。トーラスは各種のCSGに非常に便利な形であるので POV-Rayはこの4次多項式をプリミティブ形状として採用した。トーラスの構文は非常に単純なので、あなたが一度2つのfloatパラメータの意味を学べば使うのが簡単なオブジェクトになる。この表題についての講義の代わりに一つ作ってみよう。そして実験してみよう。 ファイルtordemo.povを作成して、以下のように編集しよう: #include "colors.inc" camera { location <0,.1, -25> look_at 0 angle 36 } background { color Gray50 } // トーラスを見やすくする light_source{ <300, 300, -1000> White } torus { 4, 1 // 大(major)半径と小(minor)半径 rotate -90*x // こうすると真上から見れる pigment { Green } } まずトレースしてみよう。なるほど、これは問題なくドーナッツである。大(major)、小(minor)半径の値を変更して何が起こるか確かめよう。では、以下のように変えてみよう: torus { 5,.25 // 主半径と副半径 フラフープみたいになった！次も試してみよう: torus { 3.5, 2.5 // 主半径と副半径 (図　ワーイ!太りすぎのドーナッツだ！) このように単純な構文なので、トーラスにはテクスチャを変えること以外他にできることがそんなにない...。なにかあるかな？ 見てみよう... トーラスは CSGでは便利なオブジェクトである。ちょっとした実験をしてみよう。トーラスとボックスの差differenceをとろう: difference { torus { 4, 1 rotate x*-90 // こうすると真上から見れる } box { <-5, -5, -1>, <5, 0, 1> } pigment { Green } } 面白い... 半分のトーラスだ。それで? それで、別の方向へはじけ飛んだようなもう一つをつけ加えよう。オリジナルの半トーラスと必要な変換を宣言して、再使用できるようにしよう: #declare Half_Torus = difference { torus { 4, 1 rotate -90*x // こうすると真上から見れる } box { <-5, -5, -1>, <5, 0, 1> } pigment { Green } } #declare Flip_It_Over = 180*x #declare Torus_Translate = 8 // 主半径の2倍 二つのHalf_Torusオブジェクトのunion(結合)を作ろう: union { object { Half_Torus } object { Half_Torus rotate Flip_It_Over translate Torus_Translate*x } } これはS字型のオブジェクトを作る。しかし現在のカメラ位置では全体を見ることができない。もう数個の輪をつけ加えよう。それぞれの方向に3つ、+z方向に沿ってオブジェクトを移動し、+y軸に関して回転させればもう少したくさん見える。Half_Torusのつなぎ目に小さいギャップが見えるのに気がつく。これはわれわれがx-z平面上から直接このシーンを見ているためである。これをさけるためにカメラのy座標を0から0.1に変えよう。 union { object { Half_Torus } object { Half_Torus rotate Flip_It_Over translate x*Torus_Translate } object { Half_Torus translate x*Torus_Translate*2 } object { Half_Torus rotate Flip_It_Over translate x*Torus_Translate*3 } object { Half_Torus rotate Flip_It_Over translate -x*Torus_Translate } object { Half_Torus translate -x*Torus_Translate*2 } object { Half_Torus rotate Flip_It_Over translate -x*Torus_Translate*3 } object { Half_Torus translate -x*Torus_Translate*4 } rotate y*45 translate z*20 } これをレンダリングするとクールな、うねった、蛇かなにかのようなのようなものを見る。しかし、われわれは実際の生活の中でみるような役に立つ物をレンダリングしたい。鎖はどうだろう？ しばらくそれについて考えてから、鎖の一つの輪が半分のトーラス2つと2つの円筒で簡単にモデル化されることが分かった。最初に新しいファイルを作ろう。あなたがtordemo.povで使ったのと同じカメラ、背景、光源および宣言したオブジェクトと変換が使える。 #include "colors.inc" camera { location <0,.1, -25> look_at 0 angle 36 } background { color Gray50 } light_source{ <300, 300, -1000> White } #declare Half_Torus = difference { torus { 4,1 sturm rotate x*-90 // こうすると真上から見れる } box { <-5, -5, -1>, <5, 0, 1> } pigment { Green } } #declare Flip_It_Over = x*180 #declare Torus_Translate = 8 半分のトーラス2つから完全なトーラスを作ろう: union { object { Half_Torus } object { Half_Torus rotate Flip_It_Over } } これは完全なトーラスを作るためには無駄の多い手段のように見えるかも知れないが、円筒を挿入する空間を作るために実は各半分を移動するつもりである。最初に、その結合(union)の前に円筒の宣言を加えなさい: #declare Chain_Segment = cylinder { <0, 4, 0>, <0, -4, 0>, 1 pigment { Green } } それから2つのChain_Segmentsをその結合(union)に加え、各側面でトーラスの副半径が一直線になるように変換しなさい。: union { object { Half_Torus } object { Half_Torus rotate Flip_It_Over } object { Chain_Segment translate x*Torus_Translate/2 } object { Chain_Segment translate -x*Torus_Translate/2 } } 二つの半トーラスを+y方向と-y方向に変換し、切り取られた端が円筒の端に一致するようにしなさい。その間隔は前もって宣言されたTorus_Translateの半分である : union { object { Half_Torus translate y*Torus_Translate/2 } object { Half_Torus rotate Flip_It_Over translate -y*Torus_Translate/2 } object { Chain_Segment translate x*Torus_Translate/2 } object { Chain_Segment translate -x*Torus_Translate/2 } } レンダリングしてご覧! 鎖の一つの輪ができた。でも、まだ終わりじゃない! 緑の鎖なんて誰も聞いたことがないでしょう? そのかわりに素晴らしいメタリックカラーを使おう。最初にトーラスと円筒の宣言の中のピグメントブロックを削除しよう。それから以下をunionの前に加えよう: #declare Chain_Gold = texture { pigment { BrightGold } finish { ambient.1 diffuse.4 reflection.25 specular 1 metallic } } それからそのunionにテクスチャを加え、そのunionを一つの輪(Link)として宣言しよう: #declare Link = union { object { Half_Torus translate y*Torus_Translate/2 } object { Half_Torus rotate Flip_It_Over translate -y*Torus_Translate/2 } object { Chain_Segment translate x*Torus_Translate/2 } object { Chain_Segment translate -x*Torus_Translate/2 } texture { Chain_Gold } } 今度は2つの輪のunionを作ろう。2番目のものは実際の鎖のようにその内側の壁がちょうど他の輪の壁に一致するように+y方向に変換されなければならない。この距離は副半径の2倍で、前に宣言された Torus_Translateの2倍- 2となる。これは以下の式で表される: Torus_Translate*2-2*y この式を以下のように宣言する: #declare Link_Translate = Torus_Translate*2-2*y オブジェクトブロックの中で、他の輪をつくるためにそれを増やすことができるように我々はこの宣言された値を使う。ここで第2の輪を90*y回転し、つながった鎖のように最初のと直角になるようにする。最後にunionを1/4スケールにし、全体が見えるようにする。: union { object { Link } object { Link translate y*Link_Translate rotate y*90 } scale.25 } これをレンダリングすると、非常にリアルな一対の鎖が見えるでしょう。もし、完全な鎖を作りたいのなら、われわれは上記のunionを宣言し、その宣言されたオブジェクトの新たなunionを宣言しなければならない。宣言されたオブジェクトからscalingを削除するのをわすれないで: #declare Link_Pair = union { object { Link } object { Link translate y*Link_Translate rotate y*90 } } ここであなたの鎖を宣言する: #declare Chain = union { object { Link_Pair} object { Link_Pair translate y*Link_Translate*2 } object { Link_Pair translate y*Link_Translate*4 } object { Link_Pair translate y*Link_Translate*6 } object { Link_Pair translate -y*Link_Translate*2 } object { Link_Pair translate -y*Link_Translate*4 } object { Link_Pair translate -y*Link_Translate*6 } } そして、最後に見やすくするために一組の変換により鎖を作りなさい。その変換はスケーリングを1/10にすることとそれぞれのつなぎ目を見やすくするための回転を含む。: object { Chain scale.1 rotate <0, 45, -45> } 図　トーラスオブジェクトは鎖を作るのに使える。 これをレンダリングすれば画面の対角方向に伸びたとてもリアルな金の鎖が見られる。 4.5 CSG オブジェクト Constructive solid geometry(構成的立体幾何)、CSGは以下の章で示すような複雑なオブジェクトをプリミティブオブジェクトを組み合わせてつくるのにパワフルなツールである。 4.5.1 CSGとは何か? CSG はConstructive Solid Geometry(構成的立体幾何)のことである。POV-Rayにはプリミティブの形状を組み合わせ複雑な立体を作ることを可能にする4つの方法がある。それらは2つまたはそれ以上の形を加える結合(union:ユニオン、和)、2つまたはそれ以上の形を組み合わせてそれらの共通領域を用いて新たな形を作る交差(intersection:インターセクション、積)、最初の形状から別の形状を引き去る差(difference:ディファレンス、差)、および結合のようであるが結合内の表面を取り除く併合(merge:マージ、結合、融合※)(透明な CSGオブジェクトに便利)である。以後のいくつかのセクションでそれぞれを詳しく述べる。 (※訳注CSGのオペレーションの訳は集合系、幾何学系、データ系で訳が統一されていないので、本翻訳では最初に記した訳を用いる。) CSGオブジェクトは非常に複雑にすることもできる。それらは深くネストすることができる。つまり、差の結合や併合の交差、交差の差、さらに併合の差の交差の結合さえも可能である。CSGオブジェクトは(ほとんどいつも)有限なオブジェクトであり、自動バウンディングに応答し、他のPOVのプリミティブ形状と同様に変換ができる。 4.5.2 CSG結合(union:ユニオン) 単純な結合(union)を作ってみよう。ファイルcsgdemo.povを作って以下のように編集しなさい: #include "colors.inc" camera { location <0, 1, -10> look_at 0 angle 36 } light_source { <500, 500, -1000> White } plane { y, -1.5 pigment { checker Green White } } x-軸の2つの方向にそれぞれ0.5単位平行移動した2つの球を追加しよう。一方の色を青他方を赤としよう。 sphere { <0, 0, 0>, 1 pigment { Blue } translate -0.5*x } sphere { <0, 0, 0>, 1 pigment { Red } translate 0.5*x } このファイルを200x150 -Aでトレーシングしてみよう。今度はこの2つの球のまわりに結合ブロックを加えよう。これで2つのオブジェクトの他に一つのCSG 結合ができる。 union{ sphere { <0, 0, 0>, 1 pigment { Blue } translate -0.5*x } sphere { <0, 0, 0>, 1 pigment { Red } translate 0.5*x } } 再びトレースしてみなさい。結合が見えるが、それぞれ単独の場合と何も変わらない。そこでこれを一つのテクスチャを持つ完全な結合として全体として変換してみよう。そこで以下のようにする。 union{ sphere { <0, 0, 0>, 1 translate -0.5*x* } sphere { <0, 0, 0>, 1 translate 0.5*x } pigment { Red } scale <1,.25, 1> rotate <30, 0, 45> } 再びこのファイルをレースしよう。あなたが見るようにオブジェクトはドラマチックに変わった。スケールと回転に別の値を使って、また別のテクスチャを使って実験してみよう。 個々のコンポーネントに対してテクスチャを割り当てる代わりにCSGオブジェクトに一つだけのテクスチャを割り当てることにはいくつかの利点がある。第一に、もしあなたのCSGオブジェクトがたくさんのコンポーネントからなる場合、オブジェクトの外観を変更する場合に一つのテクスチャを変更するだけですむので、一つのテクスチャを用いる方がとても簡単である。第二にテクスチャを一度だけ解析すればよいので、より速くファイルの文法的解析ができる。これは大きいシーンやアニメーションをやっているときには大きなファクターとなる。第三に一つのテクスチャだけを使うことはテクスチャが一度保存されるだけでCSGオブジェクトのすべてのコンポーネントから参照できるのでメモリを節約することができる。テクスチャをn個すべてのコンポーネントに割り当てることは、n回保存されることを意味する。 4.5.3 CSG交差(intersection:インターセクション) 次の種類のCSGオブジェクト、交差(intersection)を説明するために、同じ球を使おう。単語unionをintersectionに変更し、scale文とrotate文を削除しよう: intersection { sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } pigment { Red } } ファイルをトレースすると2つの球の代わりにレンズ型のオブジェクト見えるでしょう。これは交差が二つの球の共有する領域(このばあい二つの球が重なるレンズ形の領域)の交わりから成るためである。われわれはこのレンズ形が好きなので次の差のデモンストレーションでも使う。 4.5.4 CSG差(difference:ディファレンス) y軸についてレンズ形の交差部を回転させると、幅の広い側面がカメラに直面する。 intersection{ sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } pigment { Red } rotate 90*y } 円筒を作ってレンズの中央にそれを刺そう。 cylinder { <0, 0, -1> <0, 0, 1>,.35 pigment { Blue } } 円筒の位置を見るためにシーンをレンダリングしなさい。差(difference)ブロックをレンズ形の交差部と円筒のまわりに以下のように置く: difference { intersection { sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } pigment { Red } rotate 90*y } cylinder { <0, 0, -1> <0, 0, 1>,.35 pigment { Blue } } } ファイルをレンダリングしなさい。円筒のあった場所にきれいに穴のあいたレンズ形の交差部が見えるでしょう。円筒が交差部分から引き去られたのである。円筒のピグメントが穴の表面を青色にすることに注意しなさい。このピグメントを取り除くと穴の表面は赤になる。 OK、こんどは少しワイルドにしよう。名前を付けるために孔のあいたレンズオブジェクトを宣言しよう。また、宣言されたオブジェクトの中のすべてのテクスチャを取り除き、代わりに最終的な結合にそれを使おう。 #declare Lens_With_Hole = difference { intersection { sphere { <0, 0, 0>, 1 translate -0.5*x } sphere { <0, 0, 0>, 1 translate 0.5*x } rotate 90*y } cylinder { <0, 0, -1> <0, 0, 1>,.35 } } このオブジェクトの複製から成る複雑な形状を作るために結合を使おう。 union { object { Lens_With_Hole translate <-.65,.65, 0> } object { Lens_With_Hole translate <.65,.65, 0> } object { Lens_With_Hole translate <-.65, -.65, 0> } object { Lens_With_Hole translate <.65, -.65, 0> } pigment { Red } } これを表現して面白いオブジェクトを確認しよう。さらにもう少し試してみよう。ピグメントブロックにフィルタ(filter)を追加することにより部分的に透明なオブジェクトを作ろう。 union { object { Lens_With_Hole translate <-.65,.65, 0> } object { Lens_With_Hole translate <.65,.65, 0> } object { Lens_With_Hole translate <-.65, -.65, 0> } object { Lens_With_Hole translate <.65, -.65, 0> } pigment { Red filter.5 } } 再びファイルをレンダリングしよう。これはかなりよく見える。ただ...結合の内部のそれぞれのレンズオブジェクトが見える。これは良くない。 4.5.5 CSG併合(merge:マージ) 上記のことが4番目のCSGオブジェクト、併合(merge)にわれわれを導く。併合は結合と同じであるが、併合内部のCGS内のオブジェクトの形状はトレースされない。このことは上記のオブジェクトの問題を取り除いてくれる。以下を試そう。 merge { object { Lens_With_Hole translate <-.65,.65, 0> } object { Lens_With_Hole translate <.65,.65, 0> } object { Lens_With_Hole translate <-.65, -.65, 0> } object { Lens_With_Hole translate <.65, -.65, 0> } pigment { Red filter.5 } } 4.5.6 CSG の落とし穴 あなたがさけなければならないいくつかの落とし穴がPOV-Ray'の CSG コードにはある。 4.5.6.1 一致表面(Coincidence Surfaces) POV-Rayは光線がCGSオブジェクトを横切る点を決定するために内部か外部かのテストを行う。一致している表面上の一点がどちらの形状に属すかを数学的に示す方法がないため、2つの形状の表面が一致したとき問題が生ずる。 次の例に注目しなさい。そこでは円筒がそれより大きいボックスに孔を切り取るために使われている。 difference { box { -1, 1 pigment { Red } } cylinder { -z, z, 0.5 pigment { Green } } } このオブジェクトをトレースするとあなたは、孔があるべき場所に赤い小斑点(speckles:スペックル)を見る。これは円筒とオブジェクトの一致している表面に起因する。一度円筒の表面を最初の視線光線がヒットすると、結果として正確な孔のレンダリングができる。そして別の時にボックスが最初にヒットすると悪い結果として孔が消えた場所に赤い小斑点があらわれる。 この問題は一致表面を除くために円筒のサイズを大きくすることにより避けることができる。それは次のようにする: difference { box { -1, 1 pigment { Red } } cylinder { -1.001*z, 1.001*z, 0.5 pigment { Green } } } 一般にあなたはCSG 差(difference)においてほんの少し大きめの引き去るオブジェクトを作らなければならない。一致する表面を探してそれらの表面を除くために適切な引き去るオブジェクトを大きくしなさい。 同じ問題がCSG 交差(intersections)でも生ずるが、それに含まれているオブジェクトをスケーリングすることによって避けることができる。 4.6 光源 レイトレースされるどんなシーンにもわれわれのオブジェクトを照らすために光が必要であり、それらは光源から来なければならない。多くの種類の光源がPOV-Rayで利用できる。そして、正しい種類の慎重な利用は非常に感動的な結果を生むことになる。光源とそれらのいろいろなパラメータの種類のいくつかを調べるために少し時間をとろう。 4.6.1 環境光源 環境光源(Ambient Light Source)は相互拡散反射(inter-diffuse reflection)の効果をシミュレートするために使われる。この相互拡散反射がないと、直接光源から照らされる面以外は完全に暗くなる。POV-Rayはキーワードambientを環境光源からの光が表面でどのくらい反射してくるかを決めるのに用いる。 デフォルトで、至る所に、そして、四方八方にその光を発する環境光源は、純粋な白(rgb<1,1,1>)である。その色を変更することは面白い効果を作るのに使える。まず第一に、シーンの全光レベルを、簡単に調節することができる。すべてのambient値を変更する代わりに環境光源を変更するだけでよい。異なる色を割り当てることによって、ムードのある赤らんだ環境光のようなすてきな効果をつくることができる。環境光源の詳細については「環境光」の章を見なさい。 以下は赤い環境光源の例である。 global_settings { ambient_light rgb<1, 0, 0> } 4.6.2 点光源 点光(Point Light)はその名の示すとおりである。点光は大きさを持たないし見えない、そしてそれが光源からどんなに離れていてもシーンの中のすべてを等しく照らす。これは、最も単純で最も基本的な光源である。2つだけ重要なパラメータ、位置と色がある。単純なシーンを設計して、点光源をそれに置こう。 新しいファイルlitedemo.povを作り以下のように編集しよう: #include "colors.inc" #include "textures.inc" camera { location <-4, 3, -9> look_at <0, 0, 0> angle 48 } 以下の単純なオブジェクトを追加しよう: plane { y, -1 texture { pigment { checker color rgb<0.5, 0, 0> color rgb<0, 0.5, 0.5> } finish { diffuse 0.4 ambient 0.2 phong 1 phong_size 100 reflection 0.25 } } } torus { 1.5, 0.5 texture { Brown_Agate } rotate <90, 160, 0> translate <-1, 1, 3> } box { <-1, -1, -1>, <1, 1, 1> texture { DMFLightOak } translate <2, 0, 2.3> } cone { <0,1,0>, 0, <0,0,0>, 1 texture { PinkAlabaster } scale <1, 3, 1> translate <-2, -1, -1> } sphere { <0,0,0>,1 texture { Sapphire_Agate } translate <1.5, 0, -2> } ここで点光源を加える: light_source { <2, 10, -3> color White } これを200x150 -Aでレンダリングしよう。オブジェクトが鋭い影を伴ってはっきり見える。湾曲したオブジェクトの光源に近い領域は最も明るい色で、光源に面しない領域は最も暗い。チェッカー模様の平面が地平線までずうっと均一に照らされている点に注意しなさい。これで平面を見ることができるがそれほど現実的ではない。 4.6.3 スポットライト光源 スポットライト(Spotlight)はとても便利なタイプの光源である。これらは写真家がスポットライトを使うのと同様に、ハイライトを加え、表面をより明るく照らすために用いられる。スポットライトには点光に比べてもう数個多いパラメータがある。それらはradius(半径)、falloff(減退)、tightness(堅固:タイトネス)、およびpoint_atである。パラメータradiusは十分に照らされる円錐の角度。パラメータfalloffは光が暗闇になる影円錐(umbra cone)の角度であり、tightnessは光のfalloffの比率を決めるパラメータである。point_atは言葉の通りスポットライトがどこを指しているかである。われわれのシーンのライトを次のように変えてみよう: light_source { <0, 10, -3> color White spotlight radius 15 falloff 20 tightness 10 point_at <0, 0, 0> } これを200x150 -Aでレンダリングするとオブジェクトだけが照らされる。残りの平面とオブジェクトの他の部分は照らされない。幅広い減退領域(falloff area)があるが影はまだ剃刀のように鋭い。これらのパラメータのいくつかをそれらが何をするか試みるためにいじってみよう。falloff値を16(通常それらはradiusよりも大きいに違いない)にして再びレンダリングしてみよう。falloffが非常に狭くなり、オブジェクトは明るいか真っ暗かどちらかになる。今度はfalloffを20に戻してtightness値を100(これ以上はきつい)にしてレンダリングしてみよう。スポットライトは前より小さく見える、しかし実際に起こったことはfalloffが急勾配になったために半径が実際より小さく見えるのだ。 tightness値が10(デフォルト)falloff値が18がこのスポットライトに最適と決め、シーンのまわりに効果をねらって2、3のスポットライトを置くことにした。ちょっと狭い青いのを、すでにある白いのに加えて置いてみよう: light_source { <10, 10, -1> color Red spotlight radius 12 falloff 14 tightness 10 point_at <2, 0, 0> } light_source { <-12, 10, -1> color Blue spotlight radius 12 falloff 14 tightness 10 point_at <-2, 0, 0> } これをレンダリングすると、シーンが素晴らしくミステリアスな空気を持つように見える。3つのスポットライトはオブジェクトの上に集まり、十分な中央の白と、一方の青、他方の赤がバランスを与える。 4.6.4 円筒光源 スポットライトは円錐形に照らすのでその効果は距離によって変化する。スポットライトから最も遠いオブジェクトに当たる光の半径が一番大きいだろう。しかし、スポットライトがどんなに遠くてもradiusとfalloffが特定のサイズである光源がほしいことがある。このために、円筒形の光源(Cylindrical Light Source)が必要とされる。円筒形の光源はスポットライトのようであるが、あなたのオブジェクトがどんなに光源からほど遠くても半径と減退(falloff)領域は同じものである。したがって、形は円錐ではなく、むしろ円筒である。あなたは、円筒形の光源をspotlightキーワードをsylinderに置き換えることによって指定することができる。すぐに、我々のシーンでこれを試しなさい。すべての3つのスポットライトを円筒光に置き換えなさい、そして、再びレンダリングしなさい。シーンがより薄暗くなったのが見える。これは円筒形の制約により光がスポットライトのように広がらないためである。より大きいradiousとfalloff値が必要である。3つの光全部のradiusを20、falloffを30にしてみよう。それが切符だ! 4.6.5 面光源(The Area Light Source) 今までのところ我々の光源の中に共通するものが一つある。それらがいずれも鋭い影を生じることである。これは現時点の光源が無限に小さい点であるからである。光源からオブジェクトが直接見えればそれらは十分明るくなり、そうでなければ完全に陰(shaded)になる。現実の世界ではこの種の完全な光と影の状況は暗黒の空間を太陽光が直接貫く宇宙空間でしか存在しない。しかし、ここ地球では光はオブジェクトのまわりで屈曲し、通常、光源は大きさをもつ。このことは光が部分的に隠されることを意味する(もう影は鋭くない)。それらは完全には照らされも陰にもならないアンブラ(umbra:暗影部※)，あるいは不明瞭の領域として知られているものを持つ。これらの柔らかい影をシミュレートするために、レイトレーサーは、その光源に寸法を与えなければならない。POV-Rayは、エリア(area:面)光として知られている機能でこれを達成する。 (※訳注:半影はpenumbra、本影はumbraであるが本影の意ではなさそう) エリア光は2つの軸方向の寸法を持つ。これらは、最初の2つのベクトルによってarea light構文の中で指定される。また、どれくらいの光がその配列にあることになっているか指定しなければならない。その値が多いと、よりきれいな柔らかい影が得られるが、レンダリングの時間はより長くなる。たいてい3*3か5*5の配列で十分である。さらに、適用するための値もオプションで指定できる。adaptive(適用)コマンドは状況に応じて必要な光だけをピクセルの値を決定するのに適用するようにレイトレーサーに知らせる。adaptiveを使わないとエリア光の中のすべての光として別々の光線が送られる。これは本当にトレースを遅くすることになる。adaptive値の高い値はよりクリーンなアンブラになるが、より長いトレース時間がかかる。たいていadaptive値は1で十分である。最後に、たぶんあなたはジッタ(jitter)コマンドを使うだろう。これは、エリア光の中のそれぞれの光の位置を少し動かすようにレイトレーサーに知らせ、密接した帯状の影から成るアンブラの代わりに影が本当に柔らかく見えるようにする。 OK、次を試してみよう。円筒光(cylinder lights)をコメントにして以下を加えよう: light_source { <2, 10, -3> color White area_light <5, 0, 0>, <0, 0, 5>, 5, 5 adaptive 1 jitter } これは白いエリア光で<2,10,-3>を中心とする。サイズはx、y軸方向に 5*5単位であり 25 (5*5)個のライトがそこにあることになる。我々はadaptiveを1にしjitterを加える。これを200x150 -Aでレンダリングしよう。 すぐに、我々は2つのものに気がつく。ポイントライトやスポットライトでトレースするよりもトレースに少し長く時間がかかる。それと、影はもはや鋭くない。すべてのまわりにすばらしいソフトなアンブラがある。もう少しよくなるまで待ちなさい。 スポットライトと円筒光は、エリア光にする事ができる。我々のシーンの中のスポットライトからの鋭い影を覚えていますか？スポットライトのために5*5配列を使うことはあまり意味がないが、より小さい配列はスポットライトのためにちょうど良い量のアンブラを与えるようにうまく働くかもしれない。やってみよう。エリア光(area light)をコメントアウトして円筒光(clynder lights)に変えると以下のようになる: light_source { <2, 10, -3> color White spotlight radius 15 falloff 18 tightness 10 area_light <1, 0, 0>, <0, 0, 1>, 2, 2 adaptive 1 jitter point_at <0, 0, 0> } light_source { <10, 10, -1> color Red spotlight radius 12 falloff 14 tightness 10 area_light <1, 0, 0>, <0, 0, 1>, 2, 2 adaptive 1 jitter point_at <2, 0, 0> } light_source { <-12, 10, -1> color Blue spotlight radius 12 falloff 14 tightness 10 area_light <1, 0, 0>, <0, 0, 1>, 2, 2 adaptive 1 jitter point_at <-2, 0, 0> } これで3つのエリア スポットライトになった。一単位の4つの(2*2)ライトの配列からなる四角形で、三つの異なる色、すべてはあなたのシーンを照らす。200x150 -Aでレンダリングしよう。これは、完全にうまくいくように見える。すべての影は小さく、タイトな、ちょうど実際のスポットライトの下でみるような影(umber)を持つ。 4.6.6 オブジェクトを光源に割り当てる 光源は見えない。それらは光がきているようにみえる位置にある。実際の大きさや形は無い。あなたが光源が見える形であってほしいのならばlooks_likeキーワードを使うことができる。あなたが選んだどんなオブジェクトでもそれに見えるように光源を指定することができる。あなたがlooks_likeを使うと、そのオブジェクトには no_shadow が自動的に適用される。これはオブジェクトが光源からの照明をブロックしないためになされる。あなたがいくらかのブロッキングが起きてほしいのならば(ランプシェードの中のように)同じことをするために単にunionを使う方が良い。そのようなオブジェクトを我々のシーンに加えよう。私がちょうどこの目的のために作った白熱電球がここにある: #declare Lightbulb = union { merge { sphere { <0,0,0>,1 } cylinder { <0,0,1>, <0,0,0>, 1 scale <0.35, 0.35, 1.0> translate 0.5*z } texture { pigment {color rgb <1, 1, 1>} finish {ambient.8 diffuse.6} } } cylinder { <0,0,1>, <0,0,0>, 1 scale <0.4, 0.4, 0.5> texture { Brass_Texture } translate 1.5*z } rotate -90*x scale.5 } ここで光源を加える: light_source { <0, 2, 0> color White looks_like { Lightbulb } } これをレンダリングすると、かなりそれらしい電球がシーンを明るく照らす。しかし我々が高いambient値を指定しないならば、電球は光源で照明されていない。+側の面で、現実の状況のように、すべての影は電球から離れて落ちる。影が鋭いので、我々の電球をエリア光にしよう: light_source { <0, 2, 0> color White area_light <1, 0, 0>, <0, 1, 0>, 2, 2 adaptive 1 jitter looks_like { Lightbulb } } 我々がx-z平面の代わりに、このエリア光をx-y平面に置いた点に注意しなさい。また、電球の実際の外観がどんな手段でも光源によって影響を受けない点に注意しなさい。電球は、他の光源によって、あるいはこの場合のように高いambient値によって明るくされなければならない。したがってこの場合はハローを使ってより面白い結果が得られるかも知れない("Hallos"の章を見よ)。 4.6.7 特殊な光源 4.6.7.1 影のできない光を使う 光源にはshadowless(影なし)キーワードを割り当てることができる。そして、そのキーワードが存在するとシーンの中で影は投げかけられなくなる。それの何が良いのかあなたはたずねるかも知れない。ときどき、あなたのオブジェクトを照らすためにあなたが選んだライトを使って正しく照明するのが難しいシーンがある。シーンの中のあらゆるオブジェクトのテクスチャに、より高いambient値を適用することは非実用的で非現実的である。それで、その代わりに、あなたはシーンのまわりに二つのフィルライト(fill light)を置く。フィルライトはshadowlessキーワードと一緒では単により薄暗い光であり、あまり良く照らされないシーンの、他の領域の照明を高める。われわれのシーンの中で一つ使ってみよう。 3つの有色のエリア スポットライトを覚えている？後ろに戻ってそれらのコメントにされた部分を元に戻して、あなたが作った他の光源はコメントにしてしまおう。そうしたら以下のように追加しよう: light_source { <0, 20, 0> color Gray75 shadowless } これはかなり薄暗いライト( Gray75 )で20単位シーンの中心より上にある。それは、平面を含むすべてのオブジェクトにバックグラウンドで薄暗い照明を与えるだろう。それをレンダリングして見よう。 4.6.7.2 ライト・フェイディング(Light Fading)を使う われわれがリアリズムを求めるならば、距離の離れた平面が均一に明るくされるのは現実的でない。現実の世界では光は進行につれ散乱し、光源から離れたオブジェクトが得る光の照らす能力は減る。これをシミュレートするために、POV-Rayでは2つのキーワードを使うことができる:完全な照明が成される距離を指定するfade_distance(フェイド距離)；そして実際の減衰の割合を決定する指数の値、fade_power(フェイド指数)。これらのキーワードをフィルライト(fill light)に適用しよう。 最初に、フィルライトを少し明るくGray75からGray50に変更しなさい。フィルライトの変更は以下のようになる: light_source { <0, 20, 0> color Gray50 fade_distance 5 fade_power 1 shadowless } これ(fade_distance 5)はフィルライトの完全な光は光源から5単位の距離離れたところまで達することを意味する。fade_powerの1の値は、減衰が線形だということを意味する(光は一定の率で落ちる)。描画して結果を見よう。 それは、確かにうまくいった！ fade_power 2 で fade_distance 10を試してみよう。再びうまくゆく。光の減退(falloff)はfade_power 2により余計に鋭くなる。そのためfade_distanceを10まで上げなければならなかった。 4.6.7.3 光源と大気(Atmosphere) デフォルト以外の定義によって、光源は大気(atmosphere)によって影響を受ける、すなわち、それらの光は大気によって拡散させられる。これらはlight sourceブロックにatmosphere offを加えることによりオフにできる。また、光源から発せられる光は大気(あるいはフォグ(fog))により減衰させられる。atmospheric_attenuation onをつけ加えると、光はそれを通過するにつれ減少する。folloffは指数で大気あるいはフォグのdistanceパラメータに依存する。あなたは、この機能が直接光源から来ている光だけに影響を及ぼす点に注意しなければならない。反射されたり、屈折させられた光は、無視される。 これらのキーワードで実験しよう。最初に大気(atomosphere)をシーンに加えなければならない。: #include "atmos.inc" atmosphere { Atmosphere2 } それで、トレースが長い時間かからずに効果が簡単に分かるように、3つのスポットライトをエリア光にしている3行をコメントにしよう: //area_light <1, 0, 0>, <0, 0, 1>, 2, 2 //adaptive 1 //jitter シーンを200x150 -Aでトレースすると、確かにスポットライトが見える。青と赤のスポットが互いに交差しているのと、頭上の白い光がシーンの中央を通って下向きに輝くのが見える。また、光源からオブジェクトまで光が下降するにつれ強度が減少しているようにスポットライトが見えるのに気がつく。赤い光はほとんどシーンの左下の部分にあたり、青い光はほとんど右下にあたる。これは大気による減衰によるもので、シーンに更なるリアリズムを与える。大気と光源の相互作用はくすんだ(煙った)、ミステリアスな外観のシーンにするがトレースには時間がかかる。スポットライトをエリアライトにするとさらに時間がかかる。これはイメージ品質とトレーシング速度のトレードオフである。 4.7 簡単なテクスチャオプション レンダリングされた絵はいままでのところオブジェクトの外観に関しては幾分退屈な物であった。いくらかの装飾的な特徴をテクスチャに加えよう。 4.7.1 表面の仕上げ(Surface Finishes) レイトレーサーの主な特徴の一つはハイライトや反射など、表面の仕上げにおいて面白いことをする能力である。素晴らしい小さなフォン(phong)ハイライト(光るスポット)を球に加えよう。それをするためにはfinishパラメータが必要である。球の定義をこのように変更しよう: sphere { <0, 1, 2>, 2 texture { pigment { color Yellow } // YellowはCOLORS.INCで定義済み finish { phong 1 } } } 前と同じ方法でレンダリングしよう。phongキーワードはオブジェクトの上で輝いているライトと同じ色のハイライトを加える。それは多くの真実味を絵に加え、オブジェクトを滑らかで輝いて見えるようにする。phong値が小さいとハイライトは明るくなくなる (値は0と1の間でないとならない)。 4.7.2 凸凹(Bumpiness)を加える あなたが加えたハイライトはわれわれの知覚がいかに多くをオブジェクトの反射特性に依存するかを示す。レイトレーシングではそこには実際は存在しない複雑なディテールをわれわれに見せるために知覚のトリックを行うことにより、これを利用することができる。 あなたがオブジェクトに対して非常にでこぼこのある表面が欲しかったと仮定しよう。たくさんの凸凹を数学的にモデル化するのは非常に難しい。しかし我々は凸凹な外観を表面の光反射をオフにするという別の方法でシミュレートすることができる。反射計算は、表面法線ベクトルと名づけられるベクトルに依存する。これは表面から離れる方向を指す表面に垂直なベクトルである。人工的に、この法線ベクトルを修正あるいはかき乱すことにより凹凸をシミュレートできる。シーンを以下のように読めるように変更しレンダリングせよ: sphere { <0, 1, 2>, 2 texture { pigment { color Yellow } normal { bumps 0.4 scale 0.2 } finish { phong 1} } } これは法線ベクトルを修正するためにバンプ(凹凸)パターン(bump pattern)を用いることをPOV-Rayに知らせる。そのbumps値 0.4は見かけの凹凸の深さを制御する。たいていバンプは約1単位の幅で、半径2の球にはあまりうまく働かない。scale 0.2はバンプを1/5の幅にするがその深さには影響しない。 4.7.3 カラーパターン(Color Patterns)をつくる オブジェクトにはソリッドカラー(単一色)以外の色も割り当てられる。複雑なパターンをpigmentブロック内で作成できる。次の例を考えよう: sphere { <0, 1, 2>, 2 texture { pigment { wood color_map { [0.0 color DarkTan] [0.9 color DarkBrown] [1.0 color VeryDarkBrown] } turbulence 0.05 scale <0.2, 0.3, 1> } finish { phong 1 } } } キーワードwoodは、木材の年輪に似た同心のリングのピグメントパターンを指定する。カラーマップ(color_map)はwoodのカラーは最初の90％の年輪(vein)はDarkTan(暗い黄褐色) から DarkBrown(暗い茶色)までがブレンドされ、残りの10％はDarkBrown(暗い茶色)からVeryDarkBrown(非常に暗い茶色)までであることを示す。turbulence(動乱)はわずかに模様をかき混ぜるので、年輪は完全な円ではない。scaleファクターは模様のサイズを調整する。 ほとんどの模様はあなたに半径1.0の球を横切る1つのフィーチャー(feature)を与えるためにデフォルトでセットアップされる。フィーチャーは大雑把には色変化として定義される。例えば木のテクスチャは半径1.0の球の上で一つのバンドを持つ。この例では、我々はベクトルに続くscaleキーワードを使って、模様をスケーリングする。ここでは、x方向に0.2,y方向に0.3にスケーリングし、z方向は1のまま変えないで置く。1より大きいscale値は要素を引き延ばす。1より小さいスケール値は要素をつぶす。そしてscale値1は要素を変えないで置く。 4.7.4 定義済みのテクスチャ POV-Rayではglass.inc、metals.inc、stones.inc および woods.incの標準インクルードファイルの中にいくつかの非常に洗練されたテクスチャがあらかじめ定義されている。そのいくつかはpigment、normal および/または finish パラメータが定義された完全なテクスチャである。またいくつかはピグメントだけあるいは仕上げだけである。われわれの球の定義を以下のように変更し再レンダリングしよう: sphere { <0, 1, 2>, 2 texture { pigment { DMFWood4 // textures.incで定義済み scale 4 // 全方向に同じ量でスケーリング // する } finish { Shiny } // finish.incで定義済み } } pigment識別子DMFWood4は定義の段階であらかじめ非常に小さく縮小されている。この例ではわれわれはこのパターンを拡大したい。一様に拡大したいのでx、y、zのスケールファクターのベクトルではなく、scaleキーワードの後ろに一つの値を置くことができる。 pigmentsとfinishesが何かを理解し使用するために、ファイルtextures.incを通読してください。現在のDMFWood4に新しいpigmentの名前を挿入したり、Shinyのところを異なるfinishに置き換えてファイルを再レンダリングしてみなさい。 ここに断片ではなく完全なtexture識別子を使う例がある。 sphere { <0, 1, 2>, 2 texture { PinkAlabaster } } 4.8 高度なテクスチャオプション(Advanced Texture Options) 他のレイトレーサーは別としてPOV-Rayには非常に強力なテクスチャ付けをする能力がある。今までのところ複雑すぎる物はいっさい試さなかった。しかし、そろそろあなたはより高度なテクスチャオプションを試すためのプログラムの構文についても大分気楽になったのではないか。 もちろん、我々はそれらのすべてを試すことはできない。POV-Rayが持つテクスチャ付けオプションをすべて使う手引き書にはより多くのページが必要である。この限られた手引きのためにわれわれはあなたにテクスチャがどのように作成されるかのアイディアを与えるために、それらのほんの少しだけを試すことで満足する。少しの練習ですぐにあなた自身の美しいテクスチャを作ることができるだろう。 4.8.1 ピグメントと法線パターン 過去のバージョンの POV-Ray はピグメントと法線パターンの間の区別をしていた。つまり、normal {... }の中で使われるパターンか pigment{... }文の中で使われるかである。POV-Ray 3.0ではこの制限は取り除かれた。すべてのパターンは "Patterns"セクションにリストされピグメントあるいは法線のパターンとして使うことができる。 4.8.2 ピグメント すべての表面は色を持たなければならない。POV-Rayではこの色をピグメント(pigment)と呼ぶ。これは単一の色である必要はない。色のパターン(模様)、カラーリスト、イメージマップさえも可能である。ピグメントはまた、最も上の層は、少なくとも部分的に透明で下の層が透けて見えるように階層化することができる。この種のピグメントを使って遊んでみよう。 ファイルtexdemo.povを作り、以下のように編集しなさい: #include "colors.inc" camera { location <1, 1, -7> look_at 0 angle 36 } light_source { <1000, 1000, -1000> White } plane { y, -1.5 pigment { checker Green, White } } sphere { <0,0,0>, 1 pigment { Red } } このファイルを速いテストレンダリング 200x150 -A で行うと、緑と白のチェッカー平面を背景とした単純な赤い玉が見える。この球をテクスチャに使おう。 4.8.2.1 カラーリストピグメント(Color List Pigments)を使う。 始める前にわれわれがすでに一種類のピグメント、カラーリストピグメントを作ったことに注意してほしい。前の例でわれわれは平面にチェッカーパターンを使った。他の2つの種類のカラーリストピグメントbrick(煉瓦) と hexagon(六角形)がある。さっそくそれらを試してみよう。最初に平面のピグメントを以下のように変更する: pigment { hexagon Green, White, Yellow } これをレンダリングすると三色の六角形パターンが現れる。このパターンが3つの色を必要とすることに注意してほしい。今度はピグメントを... pigment { brick Gray75, Red rotate -90*x scale.25 } と変えてみよう。 結果のイメージに注目すると、平面が煉瓦パターンに変化したのがわかる。平面上に正確にパターンが現れるためにはパターンを回転しなければならない点に注意してほしい。このパターンは通常垂直な表面で使われるように設定されている。また、このパターンをより簡単に分かるようにするには、少しパターンを縮小する必要がある、これらのカラーリストピグメントをあなたの好みの床ができるまで自由に試してください。 4.8.2.2 ピグメントとパターンを使う(Using Pigment and Patterns) われわれの球を3つの色から成るカラーマップとパターンを用いてテクスチャ付けしよう。ピグメントブロックを以下のように置き換えよう。 pigment { gradient x color_map { [0.00 color Red] [0.33 color Blue] [0.66 color Yellow] [1.00 color Red] } } これをレンダリングすると縦縞の面白い模様が得られる。gradient(傾斜)の方向を yにしてみよう。こんどは縞が水平になった。gradient方向をzにしよう。縞は今度は同心円のようになる。このようにgradientの方向は直接にはカメラとは関係ない。方向を xに戻してピグメントブロックに以下の変更を加えよう。 pigment { gradient x color_map { [0.00 color Red] [0.33 color Blue] [0.66 color Yellow] [1.00 color Red] } rotate -45*z // <- この行を加える } 今、垂直な棒は、45度の角度で傾斜させられる。すべてのパターンは、このように回転させることができて、スケーリングさせることができて、移動することができる。こんどは別のパターンを試そう。一回ずつ、gradient x に次のキーワードを代入し、トレースし結果をみなさい: bozo(ボウゾウ)、marble(大理石)、agate(めのう)、granite(花崗岩)、leopard(豹)、spotted(まだら)、および wood(木) (もしお好みなら「パターン」の章にリストされているすべてのパターンがテストできる)。 これらをレンダリングするとそれぞれの結果は少しずつ異なるパターンである。しかし本当に良い結果を得るためにはそれぞれのパターンは修正する必要がある。 4.8.2.3 パターン修飾語(Pattern Modifiers)を使う いくつかのパターン修飾語を見ることにしよう。最初にパターンタイプをbozo(ボウゾウ)にし、以下の変更を加えよう。 pigment { bozo frequency 3 // <- この行を加える color_map { [0.00 color Red] [0.33 color Blue] [0.66 color Yellow] [1.00 color Red] } rotate -45*z } frequency 修飾語は単位サイズあたりのカラーマップの繰り返し回数を決める。この変更で最初に見た bozoパターンがより多くの帯を持つようになる。パターンタイプを大理石(marble)に変更しよう。前にこれをレンダリングしたときには帯状のパターンがgradient yと同様に見え、実際marble(大理石)には全く見えなかった。なぜならmarbleはgradientの一種であり、大理石に見えるためには別のパターン修飾語が必要である。その修飾語はturbulence(動乱)と呼ばれる。frequency 3 の行をturbulence 1 に変更し、再びレンダリングしよう。良くなった! 今度は、frequency 3 をturbulenceの右に戻して別のを見よう。さらに面白くなる! でも、待ってくれ、もっといいのを作ろう! Turbulenceはそれ自身いくつかの修飾語を持つ。あなたはturbulenceをいくつかの方法で調整できる。第一に、turbulenceキーワードに続くfloat(浮動小数点数値)は値が大きいほどより動乱が増す。第2にomega(オメガ)、lambda(ラムだ)、および octaves(オクターブ)キーワードをturbulenceパラメータに用いることができる。以下を試してみよう: pigment { marble turbulence 0.5 lambda 1.5 omega 0.8 octaves 5 frequency 3 color_map { [0.00 color Red] [0.33 color Blue] [0.66 color Yellow] [1.00 color Red] } rotate 45*z } これをレンダリングすると動乱が変化し、別のパターンのように見える。さらに、turbulence、lambda、omegaとoctaveの数値で、それらが何をするか見るために遊びなさい。 4.8.2.4 透明ピグメントと階層化テクスチャを使う ピグメントは用いる色のrgb値を与える数値で記述される(color rgb<1, 0, 0>は赤を与える)。しかしこの構文は rgb値以外の物も与えることができる。以下のように変更することでフィルタリング透明度(filtering transparency)を指定することができる: color rgbf<1, 0, 0, 1>。f はフィルタ(filter)を示し、POV-Rayの用語ではフィルタリング透明度である。値が1の場合は色は完全に透明であるが、ピグメントが何であるかにより光を選択する。この場合はその色は赤いセロファンのような透明な赤になる。 別の種類の透明度(transparency)が POV-Rayにある。それは透過率(transmittance)あるいは無フィルタリング透明度(non-filtering transparency)(キーワードは transmit)である。それはピグメントによる光の選択をしない点でフィルタと異なる。それはすべての光を不変に通過させる。これは以下のように指定する: rgbt<1, 0, 0, 1>。 別の種類のテクスチャ:階層化テクスチャ(layered texture)を作るためにいくつかの透明ピグメントを使おう。前の例に戻り次のテクスチャを宣言しなさい。 #declare LandArea = texture { pigment { agate turbulence 1 lambda 1.5 omega.8 octaves 8 color_map { [0.00 color rgb <.5,.25,.15>] [0.33 color rgb <.1,.5,.4>] [0.86 color rgb <.6,.3,.1>] [1.00 color rgb <.5,.25,.15>] } } } } このテクスチャは陸(land)の領域である。今度は以下の宣言により海(sea)の領域を作ろう。 #declare OceanArea = texture { pigment { bozo turbulence.5 lambda 2 color_map { [0.00, 0.33 color rgb <0, 0, 1> color rgb <0, 0, 1>] [0.33, 0.66 color rgbf <1, 1, 1, 1> color rgbf <1, 1, 1, 1>] [0.66, 1.00 color rgb <0, 0, 1> color rgb <0, 0, 1>] } } } } 海がどのようなくすんだ青い領域であり、陸が下のテクスチャを通して見せるほど澄んだ領域であることに注意しなさい。 すぐに、もう一つのテクスチャを宣言しよう。渦を巻いている雲で大気をシミュレートするために。 #declare CloudArea = texture { pigment { agate turbulence 1 lambda 2 frequency 2 color_map { [0.0 color rgbf <1, 1, 1, 1>] [0.5 color rgbf <1, 1, 1,.35>] [1.0 color rgbf <1, 1, 1, 1>] } } } 今度は我々の球に以下のすべてを適用しなさい。 sphere { <0,0,0>, 1 texture { LandArea } texture { OceanArea } texture { CloudArea } } レンダリングすると、これはかなり良い演出の小さな小惑星を得る。でももっと良くすることができる。われわれは雲の見え方がどうも気に入らない。これをもっとリアルにする方法がある。 4.8.2.5 ピグメントマップ(Pigment Maps)を使う ピグメントはあなたがpigmentで使えるのと同じパターンのキーワードを用いて、カラーマップ(color_map)におけるカラーと同じ方法で、一緒に混ぜることができる。このパワフルな機能の可能な包含関係(implications)をあなたに印象づける代わりにそれを試してみよう。 以下の宣言を追加しなさい。他の宣言より前にそれらが位置することを確認しなさい。 #declare Clouds1 = pigment { bozo turbulence 1 color_map { [0.0 color White filter 1] [0.5 color White] [1.0 color White filter 1] } } #declare Clouds2 = pigment { agate turbulence 1 color_map { [0.0 color White filter 1] [0.5 color White] [1.0 color White filter 1] } } #declare Clouds3 = pigment { marble turbulence 1 color_map { [0.0 color White filter 1] [0.5 color White] [1.0 color White filter 1] } } #declare Clouds4 = pigment { granite turbulence 1 color_map { [0.0 color White filter 1] [0.5 color White] [1.0 color White filter 1] } } 今度はこれらの宣言されたピグメントをわれわれの小惑星の上の雲の層に使おう。宣言された雲の層を以下と取り替えなさい: #declare CloudArea = texture { pigment { gradient y pigment_map { [0.00 Clouds1] [0.25 Clouds2] [0.50 Clouds3] [0.75 Clouds4] [1.00 Clouds1] } } } これをレンダリングしなさい。すると、あなたは惑星地球での天気模様のように見える非常に注目すべき模様を見るだろう。それらは、異なる緯度で見られる異なる天気の種類をシミュレートしているバンドに区切られる。 4.8.3 法線(Normals) POV-Rayのオブジェクトはとてもスムーズな表面を持つ。これはそれほどリアルだとはいえないのでオブジェクトの法線を乱すことによってオブジェクトの滑らかさを乱す。表面法線は表面に垂直なベクトルである。この法線を変えることによって表面はでこぼこになり、しわになり、あるいは多くの模様のいずれかを利用できる。それらのいくつかを試そう。 4.8.3.1 基礎的な法線修飾語(Normal Modifiers)を使う 小惑星球をコメントアウトしてファイルの最後に新しい単純な単色の球を作ろう。 sphere { <0,0,0>, 1 pigment { Gray75 } normal { bumps 1 scale.2 } } ここでわれわれはpigmentブロックに加えて、normalブロックをつけ加えた。(注意:一緒に変換させる必要や階層化テクスチャの一部である必要がなければ、これらはtextureブロックに含まれる必要はない)。これがどのように見えるか見るためにレンダリングしなさい。一つずつキーワードbumpsに以下のキーワードを代入しなさい: dents(くぼみ)、wrinkles(しわ)、ripples(波紋)、および waves(波) (あなたは「パターン」にリストされたすべてを試すことができる )。それぞれをレンダリングし何に見えるか見なさい。キーワードに続く浮動小数点数値を変えて遊びなさい。scale値も変えてみなさい。 面白さを増すために平面のテクスチャを以下のnormalを加えた単色の物に変更しなさい。 plane { y, -1.5 pigment { color rgb <.65,.45,.35> } normal { dents.75 scale.25 } } 4.8.3.2 法線を混合する(Blending Normals) Normalsはpigmentsと同様に階層化できる。しかし結果は予想外の物となる。 sphere { <0,0,0>, 1 pigment { Gray75 } normal { radial frequency 10 } normal { gradient y scale.2 } } あなたが見るように、結果のパターンはradial(放射)でもなくgradient(勾配)でもない。それは最初に放射状のパターンを計算し、それから傾斜パターンの計算をすることによる結果である。結果は単純に加法的である。これをコントロールすることは難しいのでPOV-Rayは法線を混合するための別の方法をユーザに提供する。 一つの方法はnormal mapsを使うことである。normal mapはpigment mapと同様に簡単に使える。球のテクスチャを次のように変えよう。 sphere { <0,0,0>, 1 pigment { Gray75 } normal { gradient y frequency 3 turbulence.5 normal_map { [0.00 granite] [0.25 spotted turbulence.35] [0.50 marble turbulence.5] [0.75 bozo turbulence.25] [1.00 granite] } } } これをレンダリングすると、球が非常に不規則な凸凹のある表面を持つのが見える。 gradientパターンタイプは法線を複数のバンドに分けるがturbulatedにより乱されるので、表面は混沌とした外観になる。しかしこのことは我々にアイディアを与える。 我々の小惑星の上に海を作るためのnormal mapと同じパターンを陸領域に使ったと仮定する。もし同じパターンと修飾語を同じサイズの球に使ったとするとパターンの形も同じだろうか？それは陸領域をでこぼこに、海領域をスムーズに作らないだろうか？試してみよう。第一に、並んだ2つの球を表現しよう。我々は模様が確かに同じものであるかどうか見ることができる。小惑星球をコメントアウトして、以下の変更を加えよう。 sphere { <0,0,0>, 1 texture { LandArea } texture { OceanArea } //texture { CloudArea } // <-これをコメントにする translate -x // <- この変換を加える } 灰色の球を以下のように変えよう。 sphere { <0,0,0>, 1 pigment { Gray75 } normal { bozo turbulence.5 lambda 2 normal_map { [0.4 dents.15 scale.01] [0.6 agate turbulence 1] [1.0 dents.15 scale.01] } } translate x // <- この変換を加える } これをレンダリングして模様が同じかどうか見よう。確かにそうであることがわかる。それで、灰色の球をコメントにして小惑星の陸領域のテクスチャを含むnormal ブロックをそこに加えよう。translateを取り除くと小惑星が再びシーンの中心に置かれる。 #declare LandArea = texture { pigment { agate turbulence 1 lambda 1.5 omega.8 octaves 8 color_map { [0.00 color rgb <.5,.25,.15>] [0.33 color rgb <.1,.5,.4>] [0.86 color rgb <.6,.3,.1>] [1.00 color rgb <.5,.25,.15>] } } normal { bozo turbulence.5 lambda 2 normal_map { [0.4 dents.15 scale.01] [0.6 agate turbulence 1] [1.0 dents.15 scale.01] } } } 結果として生ずるイメージを見ると確かに我々の考えがうまくゆくのがわかる。陸領域は凸凹で海領域はスムーズである。雲層の背景を加えなさい、そして、我々の小惑星は完成である。 ここでは紙面の制約のためカバーできなかった非常に多くのものがある。あなた自身でslope_map(傾斜マップ)、average(平均)、およびbump_map(バンプマップ)を調査するための時間をとってほしい。 4.8.4 フィニッシュ(Finishes:仕上げ) POV-Rayのテクスチャの最後はfinish(仕上げ)である。finishはオブジェクト表面の性質をコントロールする。finishによりオブジェクトを輝かせたり反射させたり、鈍い感じにしたり、なめらかにしたりできる。また、透明ピグメントを光が通過するときに何が起こるか、完全にはなめらかでない表面で光がどのように拡散するか、薄いフィルムによる干渉効果を持つ面で光が反射するとき何が起こるかを指定することができる。与えられたオブジェクトのfinishを指定するためにPOV-Rayには12の異なる特性がある。それらは ambient(環境光)、diffuse(拡散光)、brilliance(ブリリアンス、光輝)、phong(フォン)、specular(鏡面)、metallic(金属)、reflection(反射)、refraction(屈折)、caustics(火線)、attenuation(減衰)、crand(クランド)、および iridescence(虹色の光彩)である。これらのパラメータを使ったテクスチャのいくつかをデザインしてみよう。 4.8.4.1 環境光(Ambient)を使う POV-Rayの中のオブジェクトが光源によって明るくされて、それらの物体の影になる部分が完全に黒くなるのは最初の2つのfinish特性ambientとdiffuseがないためである。 Ambient(環境光)は、直接光源から届かないシーンのまわりに散乱させられる光をシミュレートするために使用される。Diffuse(拡散光)は直接光源から来る光がどのくらいの量見えるかを決定する。これらの2つのキーワードは環境光のシミュレーションを制御するために一緒に働く。それを示すためにわれわれの灰色の球を使おう。また、背景面をオリジナルの緑と白のチェックカーパターンに戻そう。 plane {y,-1.5 pigment {checker Green, White} } sphere { <0,0,0>, 1 pigment {Gray75} finish { ambient.2 diffuse.6 } この例では、ambient と diffuseのデフォルト値を使っている。 これをレンダリングしてその効果を確認したら以下の変更をfinishに加えよう。 ambient 0 diffuse 0 球で反射される光源からの光が全く無いように指定してしまったので球は黒くなる。diffuseをデフォルトの0.6に戻そう。 今度は光源からの光が当たる部分はグレイの表面色が見える。しかし陰の部分は完全に黒い。今度はdiffuse を 0.3 に ambient を 0.3にしてみよう。 今度の球はほとんど平らに見える。これはわれわれが本当に高い程度のambient光を指定し、光源から来る光のほんの少しの量がカメラに向かって拡散反射するように指定したからである。ambient と diffuseのデフォルト値はかなり良い平均値で、出発点には良い。ほとんどの場合、ambient値は0.1... 0.2で十分で通常のジョブではdiffuse値は 0.5... 0.7 である。二つの例外がある。もし、高い屈折または反射値を持つ完全に透明な表面に対してはambientとdiffuse両方とも低い値がベストである。 ここにその見本がある。 sphere { <0,0,0>, 1 pigment { White filter 1 } finish { ambient 0 diffuse 0 reflection.25 refraction 1 ior 1.33 specular 1 roughness.001 } } } これは、明らかにガラスである。ガラスはほとんどすべての外観をその周囲からとる材料である。ガラスを照らす光のすべては実際には反射あるいは透過させられるため表面のほとんどは見えない。他の見本についてはglass.incを見なさい。 あなたが与えられたシーンの中のライティング状況において独立して完全に照らされるオブジェクトを必要とするならばambient値を1にdiffuse値を0にしなさい。これは、すべての陰影法(shading)を排除して、どの点においてもそのオブジェクトに全面的で最も明るい色値を単に与える。これは、白熱電球のような光を発するオブジェクトをシミュレートするために、そして、シーンの中のどこからも適切に照明されていない空のためにも良い。 これを我々の球で試そう。 sphere { <0,0,0>, 1 pigment { White } finish { ambient 1 diffuse 0 } } } これをレンダリングすると、ハイライトも陰影をつけられた部分もなしで目をくらませるような白い球を得る。これは、街灯を作成するのにかなり良いだろう。 4.8.4.2 表面ハイライト(Surface Highlights)を使う 上記のガラスの例の中でその表面に明るい小さなホットスポットがあるのに気がついた。これは、その球に硬い、光る外観を与えた。POV-Rayは、あなたに鏡面のようなハイライトを指定する2つの方法を与える。その第一は、フォン(Phong:あるいはフォーン)ハイライトと呼ばれる。通常、フォンハイライトは、2つのキーワードを使用して記述される:phong とphong_sizeである。phongに続く浮動小数点数(float)値はそのハイライトの明るさを決定し、phong_sizeに続く浮動小数点数値はサイズを決定する。これをためそう。 sphere { <0,0,0>, 1 pigment { Gray50 } finish { ambient.2 diffuse.6 phong.75 phong_size 25 } } これをレンダリングすると、我々は、その球に一種のプラスチックの外観を与える本当に幅広い、柔らかいハイライトを見る。phong_size を 150に変更しよう。これはより小さいハイライトを作成し球の外観をより硬く輝いたものにする。 もう一種の別な方法で計算されるハイライトがある。それは鏡面(specular)ハイライティングと呼ばれる。それは、specularキーワードを使用し指定されて、もう一つのキーワードroughnessに関連して働く。これら2つのキーワードがphongとphong_sizeと同様に一緒に働き、表面の外見上の光沢を変え、ハイライトを作る。specularをわれわれの球に使ってみよう。 sphere { <0,0,0>, 1 pigment { Gray50 } finish { ambient.2 diffuse.6 specular.75 roughness.1 } } } 結果を良く見ると、phong_sizeに25を使った時と同じように、幅広い、柔らかいハイライトが見える。roughness を.001に変えレンダリングしてみよう。今度は、我々が150のphong_sizeを使用したときと同様の小さい、きついハイライトを見る。一般的に言って、specularはphongよりわずかにより正確で、したがってわずかにより現実的である。しかし、あなたはテクスチャを設計しているとき両方の方法を試してみるべきである。phongとspeculaの両方がfinishで使われる場合もある。 4.8.4.3 反射(Reflection)とメタリック(Metallic)を使用する 手を取って説明するもう一つのハイライトに関する表面パラメータがreflectionである。よく光る表面は大抵ある程度の反射性を持つ。例を見てみよう。 sphere { <0,0,0>, 1 pigment { Gray50 } finish { ambient.2 diffuse.6 specular.75 roughness.001 reflection.5 } } } 現在、我々の球は緑と白い格子縞模様にされた平面と黒い背景を反映するように見える。しかし、その球の灰色の色は不適当に見える。これは、より低いdiffuse値が必要とされるもう一つの機会である。一般に、高いreflectionのときdiffuseはより低くなければならない。そのdiffuseを 0.3にambient値を0.1に低下させ再レンダリングしてみなさい。だいぶ良い。我々の磨かれた金のボール{子を生んでいる}のように光る球を作成しよう。 sphere { <0,0,0>, 1 pigment { BrightGold } finish { ambient.1 diffuse.1 specular 1 roughness.001 reflection.75 } } } かなりイメージに近いがハイライトがあまり良くない。より金属のように見える表面を作成するために、metallicキーワードが使用される。それを追加し違いを見よう。 sphere { <0,0,0>, 1 pigment { BrightGold } finish { ambient.1 diffuse.1 specular 1 roughness.001 reflection.75 metallic } } } そのハイライトが光源の色と言うよりむしろ表面の色をとったものが見える。これは、その表面により金属的な外観を与える 4.8.4.4 屈折(Refraction)を使う 透明なオブジェクトは、光がそれらを通り抜けるのを許す。オブジェクトの光学密度が物質によって異なるために、ある物質から別の物質に光が通るときに、その光は曲げられる。これは屈折と呼ばれる。水とガラスは両方ともそのように光を曲げるので、水やガラスを作るために、POV-Rayはあなたに屈折を指定する方法を与える。それは、キーワードrefractionとiorで行われる。オブジェクトを通り抜ける光の量は、フィルタリングや透過率チャネルの値によって、そのpigmentの中で決定される。あなたは屈折をonにするかoffにするかだけを、それぞれ1か0の値(あるいは論理値onおよびoff)のrefraction値で指定しなければならない。この理由の詳細な説明はセクション「屈折」を見なさい。 屈折の程度、すなわち起こる曲げの量は、屈折率(index of refraction)の省略のキーワードiorによって与えられる。もし、作ろうとしている物質の屈折率を知っているなら、われわれはそれを使用するだけでよい。たとえば、水は1.33である、ガラスが1.45のあたりにある、そして、ダイヤモンドは1.75である。我々が以前に使用したガラス製の球の例に戻ろう。 sphere { <0,0,0>, 1 pigment { White filter 1 } finish { ambient 0 diffuse 0 reflection.25 refraction 1 ior 1.45 specular 1 roughness.001 } } } これを再びレンダリングして、その球を通して見える平面が、どのようにゆがめられて、さかさまになったかを気をつけて見る。これは、その球を通り抜けている光が指定された程度で曲げられあるいは屈折させられているためである。iorを1.25に引き下げてみなさい。1.75までそれを増やしてみる。そのゆがみが、どのように変わるかが分かる。 4.8.4.5 光の減衰を加える 透明なオブジェクトはそれを通過する光の強度を減少するように作ることができる。現実には不純物による光の散乱によるものである。二つの浮動小数点数値がこの効果を決定する。fade_distance は光が元の輝度の半分になるまでに移動する距離である。fade_powerは減少(falloff)の程度を表す。この例を試してみよう。 sphere { <0,0,0>, 1 pigment { White filter 1 } finish { ambient.1 diffuse.1 reflection.15 refraction 1 ior 1.45 specular 1 roughness.001 fade_distance 5 fade_power 1 } } 図 半透明な球の火線 これは、光のすべては通らないわずかに曇った外観の球を示す。このテクスチャの面白いバリエーションのために、iorを1.15に下げてreflectionを0.5まで上げてみなさい。 4.8.4.6 模造火線を用いる 4.8.4.6.1 火線(Caustics)とは何か? 最初に、我々の台所の食器棚をあけよう。我々は透明なガラスあるいはクリスタルのグラスを探している。もしその表面に刻まれた模様があればとても良い。一つずつ、我々は明るいランプの下にそれらを置き、そして、それらが机かテーブルに投げかけた影を観察しよう。接近して見ると、我々は影の中に明るい領域を見つけるだろう。これらは、ガラスの容器の屈折の性質により十分に光が集結させられた明るい地点を作っている場所である。模様がガラスの表面にあるならば、我々は明るい領域の外に形づくられたパターンを見るだろう。それらの明るい領域は、屈折に起因する火線、屈折火線(refractice caustics)である。また、ガラスから反射された光で引き起こされるテーブルの上の光の明るいパターンがあるだろう。これらは反射火線(reflective caustics)と呼ばれる。 一度われわれが何を探していたかが分かると、多くの日常の状況で火線を見つけることができるだろう:拡大鏡の投げかける影にもそれがあり、流れる水槽の中の光もそれを生ずるだろうし、もみくちゃにされたセロハンの一部分を通る光もそれをテーブルの表面に投げかけるし、他にもある。明るく晴れた日にスイミングプールの底にも見ることができる。Caustics(火線)は、レイトレースされた画像に実際にそのような項目のリアリズムを与えることができる微妙な照明効果である。 POV-Rayは屈折火線を模造するアルゴリズムを使う(反射火線は不可能である)。(標準の)レイトレーシング処理においては特有の制限がある。一般に、光学的試験やわずかな非常に特殊な建築上の照明プロジェクトのようなある種の光のシミュレーションアプリケーションにおいてはそれが不適当になる。火線を含む完全な光のシミュレーションを行うためには(path-tracing(経路追跡)、photon-tracing(光量子追跡)あるいはbi-directional ray-tracing(双方向レイトレーシング)のような)相当に多くの詳細にわたる計算を行う方法が必要となり、非常に時間がかかり平均的なプラットホームでは非実用的である。 このことは、われわれが最良の見かけを得るために火線をいじくり回さなければならないことを意味する。しかしほんの少しの実験で、実際のものに匹敵する非常に近いものを作ることができることが分かるだろう。進むべき最良の道、常に可能な場所は、われわれがトレースしようとするものの例を研究することである。火線のパターン知り、それから満足するまで最終的な絵を調整する必要がある。 4.8.4.6.2 シーンに火線を適用する 火線(Caustics)は、仕上げ(finish)の範囲下の新しいテクスチャ特性である。われわれは仕上げにcausticsキーワード加えることにより透明な、屈折するオブジェクトの影にそれを適用する。手始めに以下の簡単な例を試してみる(ファイルcaustic1.pov参照)。 #include "colors.inc" #include "textures.inc" camera { location <0, 15, -40> look_at <-2, 0, 1> angle 10 } light_source { <10, 20, 10> color White } // 影を見るために退屈な床を置く plane { y, 0 pigment { Grey } } // ここで火線特性を持たせるためのものが適用される sphere { <0, 3, 0>, 2 texture { Glass3 finish { caustics .6 } } } 図 スイミングプールの火線。 これをレンダリングすると、画像の右上の角に平面から上に少し浮いたわれわれの球と視界の中心部を横切ってのたうつように投げかけられた影を見る。その中心にあるのが基本的な火線である。その中心の明るい領域が、通常、屈折性により影の中央に集中した光を示す。 これが残す唯一の疑問は以下の通りである:causticsキーワードに続く浮動小数点数値は何か?それが火線の調整についての我々の議論の出所である。飲み物用のグラスを覚えている？もしそれがかなり薄い壁で厚いガラス製の底のものであると、それが投げかける影の中でわれわれの意味するものを見るだろう。上で、より薄い壁の場合(より小さい屈折により)、火線は影にわたりあまりはっきりしない、より均一な拡散をする。しかしより厚い、より屈折する底の部分にから投げかけられる影の部分では、火線は急激により明白になり、その中心ではよりきつく焦点に集まる。 もちろんこれはシミュレートされた火線であるので、火線が焦点に集まるか拡散するかの程度とオブジェクトの形状、大きさ、屈折しやすさの間の対応は無い。しかし我々は手作業でcausticキーワードに続く浮動小数点数値でそれをコントロール可能である。この値がゼロに近い値を持つと、より拡散した薄暗い火線が得られ、1に近くなるとよりきつく焦点に集まったはっきりとした火線が得られる。1になると、厚い、よく屈折する鉛ガラスの火線が得られ、0.1ではより中空のガラス球のように見える。上のシーンで値を0.1から1.0までにして再レンダリングしてこれを試そう。そして得られる火線の違いを観よう。 範囲外の値でもまた動作する。1より大きな値はとてもとてもきつく焦点を結んだ火線になる。負の値は、ただ変な平坦なものだが面白い。本質的に、オブジェクトはいろいろな奇怪な方法で明るくされ、そして影はそれ自身の写真のネガのようななる。1950年代のSFの光線銃の効果のような物である。それは奇妙に見え、写実的ではないが、もしシュールリアリズムが好きならば少なくとも一度は試して、万一それが欲しくなったときに備えてその効果を心の中にファイルしておきましょう。 4.8.4.6.3 火線と法線 人々が一般に考えるために立ち止まるよりユニークな方法で、POV-Rayは表面法線の動揺を使用する。我々がテクスチャの中で表面法線を適用するとき、われわれが実際はまったく表面を変化させないのに、個々の地点に落ちるそれぞれの照明を計算する目的のために、むしろPOV-Rayにまるで変化されたように表面を処理するように告げることになる。要するに、それが光と影のトリックである。鋭すぎる視線の角度では見ないものと仮定すると、オブジェクトの表面のゆがみの錯覚が効果的に作成される。 また、火線は代用のトリックである。我々が上で見たように、そして十分確かに、まるでそれらのパターンが真にそこであったように、それらがテクスチャ法線パターンに反応するように設計されている。飲み物用のグラスの実験を覚えている?もし表面に模様の刻まれたグラスを見つけたなら、われわれは多分、その模様はまたグラスが投げかける火線をショーアップしたということをノートしただろう。法線が適用された透明な表面がある場合、それはその表面により投げかけられる火線をその法線パターンをまねるようにするだろう。したがって影の中にそれはショーアップされる。 以下は我々が意味するものの例である:それは単に水泳プールの中の水を表す。われわれは、水を表すための上と、プールの床を表すための下の平面までこれを抽出した。喫水線の下のカメラは、床を見ていて、光源は上に高い。(see caustic2.pov). #include "colors.inc" // われわれのカメラは水中にあり、できる火線を一番良く //見るためにプールの底を見ている camera { location <0, -5, 0> look_at <0, -10, -5> } light_source { <0, 100, 49.5> color White } // プールの底... plane { y, -10 texture { pigment { color rgb <0.6, 0.7, 0.7> } finish { ambient 0.1 diffuse 0.7 } scale 0.01 } } // 水面 plane { y, 0 texture { pigment { rgbf <0.6, 0.67, 0.72, 0.9> } normal { bumps .6 scale <.75, .25, .25> rotate <0, 45, 0> } finish { caustics .9 } } } 我々が水面に与えたバンプ(bumps)は、プールで軽いそよ風がその上に吹いた時を形づくる小さい、ランダムな山と谷を表すことを意味する。我々は何かがさっきどこかで跳ねたようなripplesかwavesをまた使うこともできたけれども、bumpも例としては十分うまく働く。 われわれは、われわれのプールの床の眺めが、ランダムなバンプパターンにほぼ対応しているたくさんの小さな火線の光のスポットを見せるのに気が付く。もし好きならば、ripples あるいは wavesを置き、火線のパターンがどう変わるか試すことができる。たとえ平面自身は何の火線も投げかけなくても(法線なして試すことができる)、POV-Rayの模造火線の生成は、もし表面に、実際にこのようなでこぼこの法線が示されていれば、でこぼこな表面の屈折がプールの底にわたって火線の光を集中させるのに十分であるということを知っている。 以前の球のような曲面では、法線パターンがまたオブジェクトにより投げかけられる火線の出現の引き金となることが分かる。十分に興味深く、これ一つだけが火線が実際に模造であることの証明であろう: われわれの水は、その仕上げ(finish)で何の屈折特性も与えられなかったけれども、その火線はまだ同じようにそこにある! 4.8.4.7 虹色の光彩(Iridescence)を使用する 虹色の光彩(Iridescence)は太陽に照らされたなめらかなオイルの面で見るものである。この虹効果は、薄膜干渉(詳細はセクション「虹色の光彩」を読み込みなさい)と呼ばれるものによってつくられる。ここではそれを使って見るだけにしよう。虹色の光彩は、iridキーワードと3つの値によって指定される:amount(量)、thickness(厚さ) および turbulence(動乱)である。amountは、全面表面色への寄与である。thicknessは、その効果の忙しさ(busyness)に影響を及ぼす。turbulenceis pigment あるいは normal turbulenceと少し異なる。あなたはオクターブ、ラムダおよびオメガをセットすることができない。しかし、わずかに異なる方法でthickness値からそのthicknessに影響を及ぼす量を指定することができる。また、0.25と1の間の値が、ここでは最もうまく働く。虹色の光彩はその表面にぶつかる光線の投射角に依存するため、最終的に、表面法線に感応する。これらのことをすべて頭に入れて、われわれのガラスの球に虹色の光彩を加えよう。 sphere { <0,0,0>, 1 pigment { White filter 1 } finish { ambient.1 diffuse.1 reflection.2 refraction 1 ior 1.5 specular 1 roughness.001 fade_distance 5 fade_power 1 caustics 1 irid { 0.35 thickness.5 turbulence.5 } } } amount、thickness および turbulenceの量を変えて、何が変わるか試して見なさい。normal ブロックを加えると何が起こるか試しなさい。 4.8.5 ハロー(光輪) 重要な注意:POV-Ray 3.0のハローの機能はいくぶん実験的なものである。これらの機能の設計とインプリメンテーション(実現)は将来のバージョンで変更される可能性が高い。我々は、3.0でこれらの機能を用いているシーンが、今後のリリースで同じくレンダリングできるか、あるいは言語構文の後ろ向き互換性を完全に維持することができるかどうかを約束することができない。 ハローは、雲、霧、火、レーザー、などのようにたくさんのさまざまな効果を作るのに使用できる強力な機能である。ハローという名前は、実際に月や太陽のまわりに見えるような光輪・暈輪(うんりん)(ハロー)を表現する能力によるものである。 (訳注:ハローの発音は[H'eilou]，科学技術用語としては「ハロー」も使う) ハロー機能の複雑さと提供されるパラメータの量の多さのために満足な結果を得るのが非常に難しい。以下のセクションは、基礎的なことから始めて、より微妙な性質まであなたが一歩一歩ハローをつくるのを手助けする。 また、ハロー機能のより良い理解を得るために、ハローのリファレンスセクションを読むことが役に立つ。あなたは、特にセクション「中空(empty)および中実(solid)オブジェクト」と「ハローマッピング」を読まなければならない。それらはハローの理解にとって不可欠である。 4.8.5.1 ハローとは何か? ハローは一種のテクスチャ機能でありオブジェクトの内部を粒子(particles)で満たすことができる。これらの粒子の分布は、いくつかの密度マッピングと密度関数(density function)を使用して加減することができる。この粒子は火やレーザーのような効果のために発光させたり雲や霧をつくるために光を吸収させることができる。 ハローはpigment、normal や finishのようにオブジェクトに付けられ、コンテナオブジェクト(container object)と呼ばれる。このオブジェクトはハローによって完全に満たされる、しかし、そのオブジェクトが中身が空()で、表面が半透明であることを確かめないと、あなたはどんなものも見ない。これが、どのように達成されるかは次のセクションの中で示される。 ハローを使って仕事をするとき、常にあなたはコンテナオブジェクトは中身が空(hollow)で半透明(translucent)であることを心の中にとどめておかなければならない。 4.8.5.2 放射(Emitting)ハロー 最も単純なタイプの一つ放射ハローから始めよう。それは、光を発するだけの粒子を使用する。他の粒子から届いている光を吸収する粒子はない。 4.8.5.2.1 基礎的なハローから始める すばらしいハロー効果をデザインするためのうまいアプローチは座標系の原点にある単位サイズの形状から始めることである。 最初の例(halo01.pov)の中で我々は、球が最も適している激しい爆発を作ろう。我々は、カメラ、光源(我々は影について考慮をしないのでshadowlessキーワードを加える)、チェッカー模様の平面とハローを含む単位のサイズの球から成っている単純なシーンから始める。 camera { location <0, 0, -2.5> look_at <0, 0, 0> } light_source { <10, 10, -10> color rgb 1 shadowless } plane { z, 2 pigment { checker color rgb 0, color rgb 1 } finish { ambient 1 diffuse 0 } scale 0.5 hollow } sphere { 0, 1 pigment { color rgbt <1, 1, 1, 1> } halo { emitting spherical_mapping linear color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 1, 0, 0> ] } samples 10 } hollow } 球はhollow(中空)にセットされ半透明の表面(pigment colorの透過率チャネルが1である)を持つことに注意されたい。これはハローのために必要である。またハローを持たない平面(plane)もhollowキーワードを持つことに注意されたい。なぜ、これが必要であるか？ 理由は、とても単純である。「中空および中実オブジェクト」セクションの中で記述されるように、他の中空でない(non-hollow)オブジェクトの内部にハローはできない。カメラが平面オブジェクト内にあるから、ハローは平面が中空でないと決して見えない(あるいはnegativeキーワードを追加し、カメラをplaneの外側にもっていく)。 すべてのそれらのハローキーワードと値は、何を意味するか？ ハローの最初のemittingキーワードはどのようなタイプのハローを使用したいかを指定するのに使う。放射ハローは光を発する。これは我々の激しい爆発のために都合が良い。 spherical_mapping(球状マッピング) および linear(線形) キーワードはハローがどのように働くかについてのより詳しい説明を必要とする(チャプター「ハロー」でより詳しく説明されている)。 上で注意したようにハローはたくさんの小さな粒子から作られている。この粒子(particles)の分布は密度関数により記述される。一般に、密度関数は我々が与えられた位置でいくつの粒子を見つけるかを示す。 数学的密度関数を明示的に使う代わりに、ハローはさまざまな粒子分布をモデル化するための密度マッピングと密度関数に依存する。 このモデルにおける最初のステップは、一次元的な範囲の値を三次元的な点へマップするための密度マッピング関数である。我々の例の中で我々は球形のマッピングを使用する。すなわち、我々は座標系の中心からの点の距離をとる。これは、なぜ座標系の中心におかれたコンテナオブジェクトから始めるのが賢いのかの理由である。すべての密度マッピングがこの中心に相対的に作成されるから、あなたがオブジェクトをどこか他の位置に置いてから始めたなら、あなたはなにも見ないだろう。全部のオブジェクト(テクスチャとハローを含む)を他の位置へ動かすことは、コンテナオブジェクトを指定位置に置く正しい方法である。 現在、我々は0〜1の範囲の一つの値を持つ。この値は、距離値の代わりに密度値を得るために密度関数を使用して変換される。この一つの値を使うだけではうまく行かない。なぜならばコンテナオブジェクトの中央から外側へ移動するにつれ密度が減少するような粒子分布が欲しいからである。 これは、密度関数によってなされる。手に入る選択肢がいくつかある。それらはハローリファレンスに記述される(セクション「密度関数」を見なさい)。我々は、1〜0の範囲の上へ0と1の間の値をマップする単純な線形の関数を使用する。それで、我々は我々の球の中央で1および表面で0の値の密度値を得る。 今、密度関数を得た。われわれが何かを見るために何をするのか？ これがcolour_mapキーワードが作用するためにどこから来たのかを示す。どんな密度に対してどんな色を使わなければならないかをプログラムに実際に知らせるために使われるカラーマップを記述するためにそれは使われる。その関係はとても単純である:カラーマップの最初の色(小さな値)は低い密度に対して用いられ、マップの後ろの方の大きな値は高い密度に対して用いられる。我々の例ではハローは最も密度の高い球の中心では黄色でその密度がゼロに達するその表面では赤が混ざる。 カラーマップの中のcolorの透過率(transmittance)チャネルは、密度フィールドの半透明性(translucency)をモデル化するために使用される。0の値は半透明性の無いことを示し、つまりその対応する密度の領域はほとんど不透明で、値1はほとんど全体が半透明であることを示す。 我々の例では color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 1, 0, 0> ] } の結果は、外側の領域が赤らんだ不透明に近く、内部が黄色がかった非常に半透明のハローが、この例のイメージをトレーシングしたあとに見られる。 図　激しい爆発をモデル化する際に用いられた基礎的なハロー。 まだ説明を必要とする一つのパラメータがある:samples キーワードである。このキーワードは、ハローを計算するためにハローを通って伝わっている光線に沿ったどれくらいのサンプルがとられなければならないかPOV-Rayに教える。低い値を使うとトレーシング速度は速くなるが、高い値にすると遅くなる。ハローがいくぶん妙に見えるならばサンプル値を増やされなければならない。つまり、もしも低いサンプリング率にすると人工的なものが現れる。より多くの詳細のためにセクション「ハローのサンプリング」を見なさい。 4.8.5.2.2 輝度(Brightness)を増やす 上のイメージのハローはなんだか暗い。ハローを通して見える背景が多すぎるためである。火のように見えない？これを修正する簡単な方法は高密度領域のハローの透過性を増加させる事である。古いカラーマップを以下のカラーマップに変えてみよう(負の透過率は正しい)。 color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 1, 0, -1> ] } halo02.povの結果を見るとハローは確かにより輝きを増すのが分かる。 図 ハローはより輝きを増す。 4.8.5.2.3 いくらかの動乱(Turbulence)を加える まだ激しい爆発には見えない。むしろ白熱したボールのようだ。なにかもっと混沌とした感じにしなければならない。そのためには動乱(turbulence)を加えなければならない。 それはturbulenceキーワードとturbulenceの量を用いればできる。以下の例のようにしよう。 sphere { 0, 1 pigment { color rgbt <1, 1, 1, 1> } halo { emitting spherical_mapping linear turbulence 1.5 color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 1, 0, -1> ] } samples 10 } hollow } ハローに動乱を加えることはハローコンテナ内部のすべての点を疑似的なランダムの方法で動かす。この結果はそこにある種の流れがあるような粒子の分布になる(turbulenceの量によって層流あるいは乱流となる)。爆発は激しい動乱であるので高いturbulence値を使うことにする。 サンプルイメージ( halo03.pov )を見ると、これは今までの白熱したボールに比べてより激しい爆発に見える。 図　動乱を加えることにより、激しい爆発はよりリアルになる。 動乱を加えるとレンダリング時間が長く掛かることに注意しなければならない。これはハローが施されたすべてのサンプルに対して時間の掛かるturbulence関数を評価しなければならないためである。 4.8.5.2.4 ハローのサイズ変更(resize) ところで、われわれの激しい爆発のイメージには一つ不思議なことがある。まだ球のように見えることである。なぜこれが起きるのか、どうやったらさけられるのか？ 前に注意したように動乱を加えることはハローコンテナ内部の粒子を周辺に移動させる。その問題はいくらかの粒子が実際にコンテナオブジェクトの外に移動してしまうためである。このことはオブジェクトの形を表すコンテナオブジェクトの表面の高密度化を生じさせる。(コンテナの外のすべてのオブジェクトは失われ、見えなくなり、結果として表面で大きな、高い可視性の密度に変化する。) これをさける簡単な方法は動乱を加えてもコンテナオブジェクトの内部に残るようにすることである。それはハローのサイズを減らすためにハローをスケーリングする事である。コンテナオブジェクトはスケーリングせずにハローだけをスケーリングする。 これはscaleキーワードをハロー構文の中に加えればできる。 sphere { 0, 1 pigment { color rgbt <1, 1, 1, 1> } halo { emitting spherical_mapping linear turbulence 1.5 color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 1, 0, -1> ] } samples 10 scale 0.5 } hollow scale 1.5 } このscale 0.5 コマンドは、この量でハロー内部の点をすべて縮尺するようにPOV-Rayに知らせる。これが、われわれが密度マッピングの後に得る半径を0から1の代わりに0から0.5に効果的に縮尺する(turbulenceは除く)。ここで動乱(turbulence)を加えると、点はコンテナオブジェクトを離れることなくどの方向にも0.5単位動くことが許される。これは実際われわれが望むことである。 我々が得るより小さいハローを補うために、球とハロー内部を1.5倍にサイズ変更する。 新しいサンプルイメージ( halo04.pov )を見ると、もうコンテナ球の形はなにも見えない。最終的にわれわれはすてきな猛爆発を得る。 図　ハローのサイズを変更するとより良く見える ハローをスケーリングする量はあなたが用いるturbulenceの量に依存する。より高いturbulence値に対してはより低いハローをスケーリングする値が必要である。これは実験するべきものである。 点が球を離れてしまうのをさけるもう一つの方法は、より大きな球、つまりより大きな半径の球を用いることである。ハローを加える前に球をスケーリングすることは重要である。そうしないとハローもスケーリングされてしまう。 これは球状マッピングおよびボックスマッピング(および非定数の密度関数)でしかうまく働かないということに注意しなさい。他のすべてのマッピングタイプは(部分的に)無限である。つまり、結果として得られる粒子の分布は無限空間をカバーすることになる(「ハロー マッピング」も参照せよ )。 4.8.5.2.5 リアリズムを改善するためにFrequencyを使う 我々の爆発のシーンのリアリズムを改善するための他の非常にうまい方法はfrequency値に1以外の値を使うことである。frequency(周波数)を使う方法はリファレンスの「Frequency 修飾語」 で説明されている。 この機能がどのように使用されるかを理解するためには、そこで使われる数学的説明はむしろ理解をあまり助けない。それはとても簡単であるけれども。frequency値はただカラーマップが密度範囲が0から1までの範囲の中で何回繰り返されるかをプログラムに教えるだけである。もし、frequencyに1(デフォルトである)が指定されるとカラーマップは密度フィールドの中で一度だけ見える。つまり、0のところのカラーは密度0に対して使われ、0.5のカラーは密度0.5の処で使われ、1のカラーは密度1に対して使われる。単純でしょう? もし、frequencyに2を選ぶと、0における色は密度0で使われ、0.5におけるカラーは密度0.25 で、1のカラーは密度0.5で使われる。密度が0.5を越えるところは何だろう? 1を越えるところにはカラーマップのエントリがないので0から再び始まる。このように0.1におけるカラーは密度0.55 ((2*0.55) mod 1 = 1.1 mod 1 =0.1)で使われ、0.5におけるカラーは密度0.75で、1のカラーは密度1に対して用いられる。 あなたが数学が得意ならば、上の例はまるで正しくないと指摘するだろう。なぜなら(1 * 2) mod 1 = 0 であり 1ではないと。我々は1よりわずかに小さい値を使うと考えるだけですべてはうまく行く。 あなたは、frequenciesの値が1より大きい場合の、ハローのカラーの急な変化をさけるために循環するカラーマップ(つまりエントリの0と1が等しいカラーマップ)を用いるべきであるということに注意すべきであった。 われわれはこの例で循環するカラーマップを用いるように変更し、frequency値を2に変更する。 sphere { 0, 1 pigment { color rgbt <1, 1, 1, 1> } halo { emitting spherical_mapping linear turbulence 1.5 color_map { [ 0.0 color rgbt <1, 0, 0, 1> ] [ 0.5 color rgbt <1, 1, 0, -1> ] [ 1.0 color rgbt <1, 0, 0, 1> ] } frequency 2 samples 20 scale 0.5 } hollow scale 1.5 } 図循環カラーマップとfrequencyの2により、よりナイスな爆発が得られる。 ( halo05.pov ) の結果を見ると、完全に満足する爆発がここで作成できた。そうじゃないかい? あなたがさけなければならない問題がfrequency値が増えた場合に残っている。しばしばあなたがfrequencyを変更するのとほとんど同じ方法でサンプルレートを増やすことが必要となる。これをしないと、あなたは多分激しくエイリアス(境界にぎざぎざが生ずること)しているアーチファクト(artifacts)(カラーのジャンプあるいは奇妙なカラーバンドのような不自然なノイズ)を得るだろう。それが起こったらsamples値をfrequencyに応じて変えれば良い(二倍のfrequencyに対し二倍のsampling rate)。 4.8.5.2.6 ハローの色を変更する 我々は素晴らしい激しい爆発を得た。しかし、我々は異なる色を使うことによっていくらかのSFタッチをそれに加えようとしたい。素晴らしい緑はどうだろう。荒れ狂いのより少ない境界で赤くなる爆発はどうだろう？ それより簡単な物はない! sphere { 0, 1.5 pigment { color rgbt <1, 1, 1, 1> } halo { emitting spherical_mapping linear turbulence 0.5 color_map { [ 0 color rgbt <0, 1, 0, 1> ] [ 1 color rgbt <1, 0, 0, -1> ] } samples 10 scale 0.75 } hollow scale 1.5 } 図 赤と緑のカラーを使うことは、予想外の結果を与える。 これは、トリックをしなければならない。halo06.povの結果を見て、あなたは失望するかもしれない。爆発の赤い中心が、どこにあるか？境界は予想されるように緑である。しかし、中心にたくさんの黄色とほんの小片の赤がある。何が起きたのか？ 我々は、我々の例題の中で光を発している放射(Emitting)ハローを使う。ハローのリファレンスの章の対応するセクションによれば(「放射(Emitting)」を参照)、このタイプのハローはハローを通り抜けても光を減少(attenuate)させない非常に小さい粒子を使う。特に観察者の近くの粒子は、観察者から遠く離れたところから来ている光を減少させない。 コンテナ球の中心の近くのハローの色を計算している間、光はその粒子分布のほとんどすべてのありうる密度を通して進む。したがってわれわれが進行するにつれ、われわれはハローの中のその時の位置にしたがって赤と緑の色を得る。これらの色の合計が使われ、黄色が与えられる(赤と緑の和は黄色である)。これがここで起こっていることである。 どのようにわれわれがまだほしいものを手に入れるか。答えは、放射ハローの代わりにグローイングハローを使うことである。グローイングハローはそれを通過している光を減らすことを除いては、放射ハローに非常に似ている。従って、他の粒子の後ろに横たわる粒子の光はその前の粒子によって減少させられる。 4.8.5.3 グローイング(Glowing:白熱している)ハロー 放射ハローに関するセクションで放射ハローとともに生ずるカラーミキシングをさけるひとつの手段としてグローイングハローについて触れた。 グローイングハローも光を吸収する点を除き放射ハローに非常に似ている。あなたはそれを「減衰ハロー」のセクションで述べられている放射および減衰ハローの組み合わせとして見ることができる。 セクション「ハローの色を変える」の中の例で、ただemittingキーワードをglowingキーワードで置き換えることによって、サンプルイメージ( halo11.pov )で示されるように我々は求める効果を得る。 図グローイングハローを使うことは、予期された結果を与える。 たとえ高密度領域の赤い色がそれほど多く見えなくても、手前の緑色にされた低密度領域が赤い光のほとんどを吸収するため、あなたが赤い色を予期した場所に黄色を得ることはない。 放射ハローとの類似性のために、我々は、このハロータイプのいくらかの試みをするためにあなたにそれを残しておく。満足な結果を得るためには、あなたは過去のセクションの中で学んだすべてのことを心に持ち続けなければならない。 4.8.5.4 減衰(Attenuating:光を吸収する) ハロー 他のシンプルなハローのタイプは減衰ハローである。これは光を吸収するだけである。それ自身は光を放射しない。 減衰ハローと他のハロータイプとの大きな違いは減衰ハローのカラーが与えられた光に沿った全粒子密度を用いたハローのカラーマップから計算される点である。他のタイプは各サンプルにおける密度から計算されたカラーの(重み付けされた)平均値から計算される。 4.8.5.4.1 雲を作る 減衰ハローは雲や煙を作るのに理想的である。以下の例では素晴らしい小さい雲を作ることを試みる。われわれは再び基本的な減衰ハローで満たされた単位サイズの球から始める(halo21.pov)。 camera { location <0, 0, -2.5> look_at <0, 0, 0> } light_source { <10, 10, -10> color rgb 1 shadowless } plane { z, 2 pigment { checker color rgb 0, color rgb 1 } finish { ambient 1 diffuse 0 } scale 0.5 hollow } sphere { 0, 1 pigment { color rgbt <1, 1, 1, 1> } halo { attenuating spherical_mapping linear color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 0, 0, 0> ] } samples 10 } hollow } 雲は普通白かグレイで赤ではないが、我々は、白黒のチェッカーボードの背景に対して良く見えるように赤い色を使う。 減衰ハローの色は、光線が、全部の粒子フィールドを通して進行した後の全累積密度から計算される。カラーマップを作るときにはこのことを心に留めておかなければならない。われわれは低い密度の領域に高い透明度を持った雲がほしいので、rgbt<1,0,0,1>の色を使い、高密度領域は不透明にしたいのでrgbt<1,0,0,0>の色を使う。 図　基本的な減衰ハローは雲を作成するのに使える。 4.8.5.4.2 ハローコンテナのスケーリング 我々が作った雲はリアルなものとはほど遠い。それは、ただ赤い、部分的に半透明のボールである。よりよい結果を得るために、すでに放射ハローのセクションで学んだ方法のいくつかを使う。われわれはよりリアルな形を得るためにいくらかの動乱(turbulence)を加える。コンテナオブジェクトの表面が見えるようになるのを防ぐためハローを縮尺し、高粒子密度領域の半透明性を減少させる。 別のアイディアはかなり良い雲をモデル化するのに使える楕円体を得るためにコンテナオブジェクトを縮尺することである。それは球の最後にscale <1.5,0.75, 1>コマンドを加えるとできる。これは球とハロー内部を縮尺する。 sphere { 0, 1 pigment { color rgbt <1, 1, 1, 1> } halo { attenuating spherical_mapping linear turbulence 1 color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 0, 0, -1> ] } samples 10 scale 0.75 } hollow scale <1.5, 0.75, 1> } halo22.povの結果を見ると、よりリアルな雲に見えるのが分かる。(色は別として)。 図ハローコンテナをスケーリングし、いくらか動乱を加えるといい結果になる。 4.8.5.4.3 付加的(Additional)ハローを加える リアリズムをさらにいくらか増やすための別の手は、複数のハローを使うことである。あなたがたとえば、積雲を見れば、それらがしばしば上部で広がり、底部でとても平らであることに気がつくであろう。 我々は、2つの付加的ハローを我々の現在のコンテナオブジェクトに加えることによってこの外観をモデル化したい(詳細のためにセクション「複数のハロー」を見なさい)。 これは以下の方法でなされる: sphere { 0, 1.5 pigment { color rgbt <1, 1, 1, 1> } halo { attenuating spherical_mapping linear turbulence 1 color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 0, 0, -1> ] } samples 10 scale <0.75, 0.5, 1> translate <-0.4, 0, 0> } halo { attenuating spherical_mapping linear turbulence 1 color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 0, 0, -1> ] } samples 10 scale <0.75, 0.5, 1> translate <0.4, 0, 0> } halo { attenuating spherical_mapping linear turbulence 1 color_map { [ 0 color rgbt <1, 0, 0, 1> ] [ 1 color rgbt <1, 0, 0, -1> ] } samples 10 scale 0.5 translate <0, 0.2, 0> } hollow } 用いた三つのハローは位置だけが異なる。つまり用いた平行移動ベクトルが異なる。二つのハローは雲の底部を形作るために用いられ、もう一つはそれらの上に位置する。3つすべてのハローのためにはより多くの空間が必要となるため、その球の半径は前の物と異なる。 halo23.povの結果はもう少し仕事が必要だが、何とか雲に見える。 図 複数のハローを用いることは、我々の雲をかなり良く改善する。 4.8.5.5 ダスト(Dust)ハロー ダスト ハローは非常に複雑なハロータイプである。これによりあなたはハロー中の粒子と光源から来ている光の相互作用を見ることができる。それらの粒子は減衰ハローのように光を吸収する。それに加えて、粒子を通り抜けてゆく光源から来た光をばらまく。これは光のビームとハローの上に投げかけられるオブジェクトの影を見えるようにする。 4.8.5.5.1 スポットライトにより照らされたオブジェクトから始める われわれはスポットライトで照明されているボックス型のオブジェクトから始める。オブジェクトが光源により完全に照らされた場合を知りたいので、現時点ではいずれのハローも使わない( halo31.pov )。 camera { location <0, 0, -2.5> look_at <0, 0, 0> } background { color rgb <0.2, 0.4, 0.8> } light_source { <2.5, 2.5, -2.5> colour rgb <1, 1, 1> spotlight point_at <0, 0, 0> radius 12 falloff 15 tightness 1 } difference { box { -1, 1 } box { <-1.1, -0.8, -0.8>, <1.1, 0.8, 0.8> } box { <-0.8, -1.1, -0.8>, <0.8, 1.1, 0.8> } box { <-0.8, -0.8, -1.1>, <0.8, 0.8, 1.1> } pigment { color rgb <1, 0.2, 0.2> } scale 0.5 rotate 45*y rotate 45*x } 図　我々が使いたいオブジェクト ご覧のようにオブジェクト全体が光源により照明されている。いくらかダストを加えることから始めよう。 4.8.5.5.2 ダストを加える(Adding Some Dust) われわれはダストハローを加えるためにboxを用いる。我々が一定の密度関数を使うため、どんな種類の密度マッピングが使われるかは重要でない。密度はハロー内部のどこでもmax_valueキーワードで指定された値を持つ(そのデフォルト値は1である)。dust_typeにより等方性の拡散が選ばれる。 box { -1, 1 pigment { colour rgbt <1, 1, 1, 1> } halo { dust dust_type 1 box_mapping constant colour_map { [ 0 color rgbt <1, 1, 1, 1> ] [ 1 color rgbt <1, 1, 1, 0> ] } samples 10 } hollow scale 5 } 図　このダストは濃すぎる。 halo32.povの結果は、あまりに明るい。ダスト(ほこり)はあまりに厚く、オブジェクトの一部が見えるだけで背景は見えない。 4.8.5.5.3 ダストの密度を減らす ハロー内部の密度は一定値1である。これはダスト密度とカラーを決定するためにカーマップエントリの位置1だけが使われることを意味する。 より薄いダストを得るために透過率値に 0.7 を用いる。 box { -1, 1 pigment { colour rgbt <1, 1, 1, 1> } halo { dust dust_type 1 box_mapping constant colour_map { [ 0 color rgbt <1, 1, 1, 1.0> ] [ 1 color rgbt <1, 1, 1, 0.7> ] } samples 10 } hollow scale 5 } 図　薄いダストはよりよく見える。 みにくくエイリアスしているアーチファクトのそばで、イメージはよりよく見える。我々は全部のオブジェクトを見ることができる、そして、背景もわずかに見える(halo33.pov)。 4.8.5.5.4 見かけのよい影(Shadows)を作る エイリアシングしているアーチファクトを減らすために、我々は3つの異なるテクニックを使う:ジッタリング(jittering)、スーパーサンプリング(super-sampling)および全サンプリングレートの増加である。 ジッタリング(jittering)はイメージがノイズを含んだように見えるようにサンプリングポイントにランダム性を加えるために用いられる。規則的なエイリアスしているアーチファクトはノイズよりも困り者だから、これは役に立つ。低いjitter値は、よい選択である。 スーパーサンプリングは強度変化の大きい領域に付加的なサンプリングをすることにより、細かい特徴を検出する。スーパーサンプリングが使われるところのしきい値と最大再帰レベルはaa_thresholdと aa_level キーワードを用いて指定される。 常に、うまくいくアプローチは、全サンプリングレートを増やすことである。これはまた、最も遅い方法であるから、常に、あなたは最初は他の方法を使ってみるべきである。それらが十分でないならば、サンプリングレートを増やさなければならないだろう。 エイリアスしているアーチファクトを減らすために以下のハローを用いる(halo34.pov)。 box { -1, 1 pigment { colour rgbt <1, 1, 1, 1> } halo { dust dust_type 1 box_mapping constant colour_map { [ 0 color rgbt <1, 1, 1, 1.0> ] [ 1 color rgbt <1, 1, 1, 0.7> ] } samples 50 aa_level 3 aa_threshold 0.2 jitter 0.1 } hollow scale 5 } 図　別のアンチエイリアス法は満足な結果を得るための手助けとなる。 今、イメージは大分良くなった。エイリアスしているアーチファクトは少しも残っていない。 我々が用いた物と同じパラメータは大気の機能のセクションで論じられる (更なる説明については「大気」を見なさい)。 4.8.5.5.5 動乱を加える ハローのダストと「大気」で述べられる大気(atmosphere)との主な違いは、ダストに対する不均一な粒子分布を選択が可能かどうかである。このことはハローが種々の密度マッピングや関数と同様にコンテナオブジェクトに制限されるという事実を含む。 不規則な分布を得る他の興味深い方法は、動乱をダストに加えることである。これは以下の例(halo35.pov)で示すように、キーワードturbulenceに続く用いる動乱の量により可能となる。 box { -1, 1 pigment { colour rgbt <1, 1, 1, 1> } halo { dust dust_type 1 box_mapping linear turbulence 1 colour_map { [ 0 color rgbt <1, 1, 1, 1.0> ] [ 1 color rgbt <1, 1, 1, 0.5> ] } samples 50 aa_level 3 aa_threshold 0.2 jitter 0.1 } hollow scale 5 } 図　ダストに動乱を加えると、より面白いものになる。 現在、我々が得たイメージは、粒子密度の変化のために非常により面白く見える。 あなたは、我々が、以前の一定値の密度関数の代わりに線形の密度関数を使用することに注意しなければならない。一定値の密度関数により、その密度は至る所同じ値になるためこれが必要である。動乱を加えても効果はない。理由は点がどこに動いてもその密度は一定値だからである。一定でない密度分布ならば動乱を加えたときに意味を持つ。 動乱のturbulence値は実際にはベクトルであるという事実から、turbulence値をその方向だけ大きな値(例えば turbulence <0.2, 1, 0.2> )を用いることにより滝のような効果を作成するのに使える。 4.8.5.5.6 色付のダストを使う もしあなたが色の付いたダストが欲しければ、ハローのカラーマップにおいて白でない色を用いることにより簡単にそれをする事ができる。その場合、あなたはまた、ダストの色によりフィルタリングされる光の量を指定するために、カラーマップにおけるフィルタチャネルを0でない値にセットしなければならない。 部分的にフィルタリングされた赤いダストを得るために以下のカラーマップの例を使いなさい: colour_map { [ 0 color rgbft <1, 0, 0, 0.5, 1.0> ] [ 1 color rgbft <1, 0, 0, 0.5, 0.7> ] } 4.8.5.6 ハローの落とし穴 ハロー機能の複雑さのため、今までのところ人々が得た経験が少ないため、まだ発見されるべき多くのものがある。 あなたが最も一般的な問題を避けるのを手助けするために最も一般的問題と落とし穴のいくつかを以下に記述する。 4.8.5.6.1 ハローが許される場所 先に述べたようにハローはオブジェクトの内側を完全に満たす。以下の例が意味をなさないと言うことは合理的な事である点を心にとどめてほしい。 sphere { 0, 1 pigment { checker texture { pigment { color Clear } halo {... } } texture { pigment { color Red } } } hollow } 何が、この例で良くないか？それは簡単なことである。ハローはオブジェクトの内部を記述するために用いられ、オブジェクトの表面がどう見えるかを記述することによりこの内部を記述することはできない。しかし、これが上記の例で何がなされたかである。あなたは、球の内部がどんなもののように見えるか想像することができるか？それは、完全にハローで満たされているか？ハローで満たされた領域と、空気で満たされた領域がそこにあるか？それらの領域はどのように見えるか? あなたは表面を見ただけでは、内部の特性を述べることはできないだろう。それは、不可能である。常に、これは心の中に保持していなければならない。 もし、上記の例がハローで満たされ、部分的にハローを隠すチェッカーボードパターンでカバーされた球を作ることを意味していたのならば、以下の構文を用いなければならない: sphere { 0, 1 pigment { checker texture { pigment { color Clear } } texture { pigment { color Red } } } halo {... } hollow } 常に、ハローは以下のようにしてオブジェクトに適用される: OBJECT { texture { pigment {... } normal {... } finish {... } halo {... } } hollow } ピグメント文、カラーマップ、ピグメントマップ、テクスチャマップ、マテリアルマップ、あるいは何でもその内部ではハローは使えない。それをすることはじゃまされないが、あなたは望むものを得ることはできない。 ハローを階層化テクスチャと共に用いることはできるが、ハローはその最下層にしか付けられないということを確認しておいてほしい(もちろんハローを見るためにはその層は部分的に透明でなければならない)。 4.8.5.6.2 コンテナオブジェクトを重ねる POV-Rayはコンテナオブジェクトを重ねることを正確には扱えない。ハローを含む2つの重なる球を作った場合、球の重なる部分は正しい結果を与えない。ハローの効果は独立に各々の球のために計算され、そして、その結果が加えられる。 ハローが正しく計算されるために、あなたが別のハローを加えたいならば、あなたはすべてのハローを一つのコンテナオブジェクトに入れなければならない。(「複数(Multiple)のハロー」も見なさい。) また、オーバーラップしない、積み重ねられた(stacked)ハローコンテナは正しく扱われる。あなたが他のコンテナオブジェクトの前にコンテナオブジェクトを置くならば、ハローは正しく表現される。 4.8.5.6.3 複数の減衰ハロー 異なるカラーマップ用いた複数の減衰ハローの使用は現在のところ可能でない。最後のハローのカラーマップがそのコンテナオブジェクトのすべてのハローに使われる。 4.8.5.6.4 ハローと中空(Hollow)オブジェクト 正確にハローの効果を表現するためにはカメラが内部にあるすべてのオブジェクトが空であることを確認しなければならない。これはhollowキーワードを用いて行う。 4.8.5.6.5 ハローコンテナのスケーリング ハローコンテナオブジェクトをスケーリングするときにはscaleキーワードの位置により大きな違いがある点を心にとどめておかなければならない。 ハロー文の前のオブジェクトのスケーリングはコンテナオブジェクトをスケーリングするだけでハローはされない。 これはあなたが動乱(turbulence)を用いることによりコンテナオブジェクトの表面が見えるのをさけたい場合に便利である。上のセクションで学んだようにturbulenceを用いると粒子はコンテナオブジェクトの外(見えない場所へ)に動く。他のマッピングタイプで記述された密度フィールドは有限の大きさを持たないため、これは球とボックスマッピングだけで動作する。 もしscaleキーワードがハロー文の後ろで使われた場合、ハローとコンテナオブジェクトの両者がスケーリングされる。これはハローを縮尺する必要がある場合に使える。 ハローは(ハローの後に)コンテナオブジェクトになされる平行移動に関係なくその外観を保持する。つまり、ハローの半透明性(translucency)、色(color)および動乱(turbulence)特性は変化しない。 4.8.5.6.6 サンプリングレートの選択 通常あなたは低いサンプリングレートから始めて、エイリアスアーチファクトが生じた場合(またスーパーサンプリングとジッタリングを用いてもそれが消えない場合)のみそれを増やすだろう。 ハローの外観はハローが実際どのように見えるかを評価するのに十分なサンプル数がある限りサンプリングレートに依存しない。このことは1つや2つのサンプルではハローの外観を決定するのには十分でないことを意味する。 それを簡単に言うと、十分な数のサンプルがあり、エイリアスアーチファクトが現れない限り、ハローはその外観をサンプル率により変えない。 4.8.5.6.7 動乱(Turbulence)を使用する 上のセクションで注意したように定数の密度関数(constantキーワード)が使われる場合、turbulenceはいかなる効果も持たない。密度が定数であれば密度は点の位置にはよらないから、あなたがどれくらいどこへ点を動かすかは問題ではない。どの位置に対しても同じ密度値を得る。 ハローに動乱(turbulence)を加えるときは常に、定数の密度関数を使ってはいけない。 4.9 特殊テクスチャを用いた作業 POV-Rayのどこかですでに見たように、多くのピグメントパターンは異なる色を混合するためにcolor_map構文を使用する。どのようにカラーマップのエントリをリストするかによって、一つの色から次の色に徐々に変化させたり、一つの色から次の色に急に変化させたりすることができる。実際、カラーマップは様々なピグメントパターンをカスタマイズするためには強力なツールであり、正しく使うためには少しの練習が必要である。個々のカラーだけを使いたい場合は、すべて申しぶん無い。しかし、全体のピグメントパターン、法線パターンあるいは他のすべてのテクスチャを混合することができるとすれば何だろう? POV-Ray 3からはそれができるようになった! エキサイティングな新しいテクスチャリングオプションを使ったテクスチャ付けを実験するために、基本的なシーンファイルを準備し、そこにあとで実験のためにサンプルのテクスチャを詰め込もう。以下の基本インクルードファイルと、カメラと光源を設定することから始めよう。 #include "colors.inc" #include "textures.inc" camera { orthographic up <0, 5, 0> right <5, 0, 0> location <0, 0, -25> look_at <0, 0, 0> } light_source { <100, 100, -100> color White } 4.9.1 ピグメントマップを用いた作業 なにか簡単なものから始めて、ピグメントマップを見てみよう。これをカラーマップと混同してはいけない。ピグメントマップはすべての他のピグメントパターンを使うことができるが、カラーマップはマップ内のエントリに個々のカラーだけしか使えない。これらに対する感触を得るために、基本的な平面の上への単純なピグメントマップの設定から始めよう。今、下記の例では、実際にそれを使う前に、使おうとするそれぞれのピグメントを宣言しようとしている。これは是非必要というわけではなく(すべてのピグメントの記述はマップのそれぞれのエントリに置くことができる）、全体をより読みやすくするためにするだけである。 // 単純な黒と白のチェッカーボード...クラシック #declare Pigment1 = pigment { checker color Black color White scale .1 } // 「サイケデリックなリング」効果の一種 #declare Pigment2 = pigment { wood color_map { [ 0.0 Red ] [ 0.3 Yellow ] [ 0.6 Green ] [ 1.0 Blue ] } } plane { -z, 0 pigment { gradient x pigment_map { [ 0.0 Pigment1 ] [ 0.5 Pigment2 ] [ 1.0 Pigment1 ] } } } OK、ここでわれわれがやったことはとても簡単なことである。いずれにせよ、もし初めからカラーマップについて勉強しているならば多分完全に理解してもらえるだろう。我々が行ったすべては、通常カラーマップがある場所に、ピグメントマップが代入され、マップのエントリとしてすでに宣言したピグメントが参照される。この例をレンダリングすると、クラシックなチェッカーボードとカラフルなリングの間で前後に変化して行くパターンを見る。Pigment1 からPigment2に変化させ、再び戻したので、我々は変化点で2つのパターンのはっきりした混合を見る。急激な変化はマップを以下のように改めることにより簡単に得られる。 pigment_map { [ 0.0 Pigment1 ] [ 0.5 Pigment1 ] [ 0.5 Pigment2 ] [ 1.0 Pigment2 ] } 4.9.2 法線マップを用いた作業 次の例として、シーンの平面(plane)を以下の物で置き換える。 plane { -z, 0 pigment { White } normal { gradient x normal_map { [ 0.0 bumps 1 scale .1] [ 1.0 ripples 1 scale .1] } } } 最初に、すべてのでこぼこを最高の効果で見せるために単一の白い色を選んだ。二番目に、0.0ででこぼこ(bunps)で1.0で波紋(ripples)となるすべてのマップが滑らかに混合されるように注意した。しかしこれはデフォルトの勾配(gradient)なので、次のサイクルの始まりでは急にbumpsに戻る。これをレンダリングすると、どこで一方の法線が他に重なるかがはっきりを見える十分に鮮明な変化を見る。それらは、滑らかに互いに混合されているが、2つの法線パターンがどのように見えるかの例でもある。 構文はわれわれが予期したものと同じである。我々は、ただマップのタイプを変えて、法線ブロックへそれを移動して、適当なバンプタイプを与えた。POV-Ray 3で、ピグメントとともに働くすべてのパターンは法線としても同様に働く(もちろん逆も)のでまるで簡単にwoodからgraniteや任意の好みのパターンに混合できるということを覚えておくことは大切である。われわれはほんの少し実験をしてそれぞれのパターンが何のように見えるかの感触を得た。 様々な混合された法線の見かけがどれだけ面白いか分かったら、一つから次のものへ徐々に変化して行く所作よりも全体にわたり完全に混合されたものを見たくなる。まあそれも可能であるが、ここより先に進まなければならない。それは平均関数(average function)と呼ばれ、ほんの少し頁を先に下ってからそれに戻ろう。 4.9.3 テクスチャマップを用いた作業 われわれはどのようにカラー、ピグメントパターンおよび法線を混合するかを知った。そして多分、仕上げ(finishes)はどうだろう?と思っている。テクスチャ全体はどうだろう?それらは両方とも以下の1つのトピックでカバーされる種類のものになる。仕上げマップ(finish map)は無いけれども、テクスチャマップはあり、単純に同じピグメントあるいは法線をマップのそれぞれのテクスチャエントリに置くことにより、簡単にそれらを仕上げマップとして役立つように適応することができる。ここに例がある。前に使った宣言されたピグメントと以前の平面を取り除き、以下のものをつけ加える。 #declare Texture1 = texture { pigment { Grey } finish { reflection 1 } } #declare Texture2 = texture { pigment { Grey } finish { reflection 0 } } cylinder { <-2, 5, -2>, <-2, -5, -2>, 1 pigment { Blue } } plane { -z, 0 rotate y * 30 texture { gradient y texture_map { [ 0.0 Texture1 ] [ 0.4 Texture1 ] [ 0.6 Texture2 ] [ 1.0 Texture2 ] } scale 2 } } 今ここでしたことは何だろう? 背景の平面は、仕上げを除いて同一である2つのテクスチャの間で垂直に交替になる。これをレンダリングすると、円筒は平面に下る途中で反射する部分を持ち、それから反射は止まり、それから始まり平面の表面の下のgradientパターンの中で再び止まる。わずかの変更で、これは任意のパターンとともに、そして、ここでしているように、オブジェクトの仕上げの異なるいろいろな部分を与えたいか、あるいはすべての異なるテクスチャを合計して与えたいかどうか、などの多くの創造的方法で使うことができる。 尋ねる人があるかも知れない:テクスチャマップがあるのに、なぜピグメントと法線マップが必要なのか? 正しい疑問である。その答えは:計算速度である。我々がテクスチャマップを使うと、POV-Rayはあらゆる中間的な点のために、それぞれのテクスチャ要素に対して複数回の計算をしなければならず、それからその点に対する正確な値を生じるために重みづけ平均を取らなければならない。ピグメントマップだけ(あるいは法線マップだけ)を使うと、全体の計算数は減少する。そしてその割引のためテクスチャのレンダリングは少しだけ速くなる。経験則として：可能な場所にはピグメントマップや法線マップを使い、特別な柔軟性が必要な場合だけテクスチャマップに戻るようにしなさい。 4.9.4 リストテクスチャを用いた作業 単純なピグメントに関して、対応するチュートリアルによれば、カラーリストパターンと呼ばれる3つのパターンがあることを知る。カラーマップを使うのに比べて、それらのシンプルながら便利なパターンはpatternキーワードの直後にカラーのリストをとるだけである。われわれが話しているのはchecker、hexagonおよびPOV-Ray 3で新しくできたbrickパターンのことである。 通常、それらはまたすべてのピグメント、法線およびテクスチャのすべてとともに、上の他のパターンとちょうど同じように動作する。唯一の違いは、エントリのマップを使う代わりに(個々のカラーを用いて行うように)パターン内にエントリをリストすることである。ここに一例がある。我々の最後の例で残した平面と宣言されたピグメントを叩いて、我々の基本的なファイルに以下を付け加える。 #declare Pigment1 = pigment { hexagon color Yellow color Green color Grey scale .1 } #declare Pigment2 = pigment { checker color Red color Blue scale .1 } #declare Pigment3 = pigment { brick color White color Black rotate -90*x scale .1 } box { -5, 5 pigment { hexagon pigment {Pigment1} pigment {Pigment2} pigment {Pigment3} rotate 90*x } } 個々のピグメントとしてそれぞれのカラーリストパターンの例を宣言することから始める。そして、ピグメントリストパターンとしてhexagonパターンを用い、それに上で行ったカラーの代わりに単純にピグメントのリストを与える。2つのrotate文がこの例の中にある。なぜならばhexagonsはy-方向に沿って整列させられるのに対して、煉瓦(bricks)はz-方向に沿って整列させられるが、われわれは元々-z方向に宣言したカメラにすべてが向くようにし、パターンの効果の範囲内で実際にパターンが見えるようにしたいからである。 もちろんカラーリストパターンはピグメントに対してだけ用いられる。しかしPOV-Ray 3のものではピグメントに対して動作するすべてのものは法線あるいはテクスチャ全体に対して適用することができる。手早くできる2つの例は以下のようになるだろう normal { brick normal { granite .1 } normal { bumps 1 scale .1 } } あるいは... texture { checker texture { Gold_Metal } texture { Silver_Metal } } 4.9.5 タイルって何? 初期のバージョンのPOV-Rayでは、タイル(tiles)と呼ばれるテクスチャパターンがあった。(いま上で見たような)簡単なcheckerテクスチャパターンの使用によって、タイルを用いて行うのと同じことが成し遂げられるので、現在それは時代遅れである。POV-Ray 3でもそれは旧いシーンファイルのための後方互換性のためにサポートされているが、その代わりにcheckerパターンを用い始めるのに今がいい機会である。 4.9.6 平均関数(Average Function) いま面白いことが得られる。上で、われわれはマップでピグメントと法線を用いたときにそれらが一方から他方へどのように変わって行くかを見ることから始めた。しかし、全体を通してパターンを滑らかに混合したいときはどうするのだろう?これが平均(average)と呼ばれる機能がとても手近になった由来である。構文は少し異なるけれども、そして予期していないとその変化に当惑させられるけれども、平均(Average)はピグメント、法線およびテクスチャマップとともに働く。ここに簡単な例がある。標準インクルードファイルとカメラ、上からの光源を用い、以下のオブジェクトを入れる。 plane { -z, 0 pigment { White } normal { average normal_map { [ gradient x ] [ gradient y ] } } } ここで何をしたかは、それをレンダリングすればすぐに自ずから説明される。われわれは垂直のと水平なgradientバンプパターンを組み合わせて、十字になったgradientを作成した。実際に、十字型の効果はずうっと平面を横切ったgradient x と gradient yのなめらかな混合である。今、文法の違いは何か? 法線マップが初期の例からどのように変わったか見てみよう。各マップエントリの左側の浮動小数点数値が取り除かれている。その値は、大抵選択したパターンに各エントリを手続き的にマッピングするのを手助けする。しかし平均(average)は一つのパターンではなく、滑らかに全体を通して混合するので、それらの値は使えない。事実、それらを含めると、どうしたことかときどきエントリが無くなったり誤って伝えられたりするような予想外の結果になる。予期するパターンの混合を得ることを保証するために浮動小数点数値は取り除く。 4.9.7 階層化テクスチャを用いた作業 POV-Rayで複雑なテクスチャを作成するための複数のカラー、パターンおよびオプションによって、われわれの最新の作品に適用するための正しいテクスチャを混ぜたり摘んだりすることに簡単に没頭できるようになる。しかし先に進むと、遅かれ速かれ特殊テクスチャにたどり着く。そのテクスチャは、すなわち、木材ような、ニスを塗られただけの、しみだらけの黄色い縞になった、誰かがそれにペンキを塗り始めたような垂直な灰色のまだらの、それからやめて、ペンキを通して見える木材の部分を残したままのようなものである。 唯一...疑問は?どのようにそのようなすべてを一つのテクスチャに与えるか?である。どのパターンもそんなにたくさんのことはできない。パニックになる前にそしてイメージマップという前に、少なくとももう一つの選択肢がある: 階層化テクスチャ(layered texture)である。 階層化テクスチャでは、一つを他の後にというように、一連のテクスチャの指定が必要なだけであり、すべては同じオブジェクトに関連づけられる。リストしたそれぞれのテクスチャはそれが現れる順序に底から一番上に順に他の上に適用される。 上位のテクスチャに対してはいくらかの程度の透明度(filter あるいは transmit)がなければならないということに注意することが重要である。そうでなければ下側のものは隠れて見えなくなってしまう。技術的にはそれをすることは正当なので警告やエラーは受けない:それは意味をなさないだけである。それは時間を費やして何もない壁に丹念な絵をスケッチし、それからその上にラテックスのペンキの真っ白いコートを投げつけるようなものである。 階層化テクスチャを持つ簡単なオブジェクトをデザインし、それがどのように働くかを見てみよう。LAYTEX.POVという名のファイルを作成し、以下の行を加える。 #include "colors.inc" #include "textures.inc" camera { location <0, 5, -30> look_at <0, 0, 0> } light_source { <-20, 30, -50> color White } plane { y, 0 pigment { checker color Green color Yellow } } background { rgb <.7, .7, 1> } box { <-10, 0, -10>, <10, 10, 10> texture { Silver_Metal // 金属のオブジェクト ... normal { // ... 打撃を被った dents 2 scale 1.5 } } // (基礎テクスチャの終わり) texture { // ... 錆のまだらを持つ ... pigment { granite color_map { [0.0 rgb <.2, 0, 0> ] [0.2 color Brown ] [0.2 rgbt <1, 1, 1, 1> ] [1.0 rgbt <1, 1, 1, 1> ] } frequency 16 } } // (錆の斑のテクスチャの終わり) texture { // ... そしてすすけた黒い点 pigment { bozo color_map { [0.0 color Black ] [0.2 color rgbt <0, 0, 0, .5> ] [0.4 color rgbt <.5, .5, .5, .5> ] [0.5 color rgbt <1, 1, 1, 1> ] [1.0 color rgbt <1, 1, 1, 1> ] } scale 3 } } // (すすけたマークのテクスチャの終わり) } // (ボックス宣言の終わり) ひゃー。これは面倒だったので読むには楽になった。何をしているのかと、どこでいろいろな部分の宣言が終わるかを示すためのコメントを含めた(それで括弧の閉じるのを忘れないですんだ!)。始めに、クラシックなチェッカーボードの床の上に簡単なボックスを作成し、背景の空に薄暗い青いカラーを与えた。面白い部分のために... まず第一に、textures.incで宣言されているSilver_Metalテクスチャを用いたボックスを作った(ボーナスポイントとして、いつかtextures.incを調べて、どのようにこの標準テクスチャが元々作られているか見てご覧)。その濫用状態を始めるために、dents法線パターンを加える。それはまるでわれわれの神秘的な金属のバックスがほんの少し叩かれたようにその表面にいくらかのくぼみの錯覚を作成する。 錆のまだらは何もないが細かい木目のgraniteパターンが暗い赤から灰色に変化し、大多数のカラーマップのために急に完全な透明になる。本当は、多分われわれはさびた部分を群がらせるためにピグメントマップを用いて、よりリアリスティックな錆の模様に追いつくことができるだろうが、ピグメントマップは他のチュートリアルセクションの課題であるのでここではスキップする。 最後にポットに三番目のテクスチャを加えた。ランダムにシフトしているbozoテクスチャが、黒くされた中心から半透明な中間の灰色まで、それから最終的にそのカラーマップの後の半分のための完全に透明まで徐々に消えて行く。これは金属のボックスの表面をさらに台無しにするすすけたやけどのマークを与える。最終結果は、一つのパターンでは生み出せない他の上に重なった複数のテクスチャパターンを用いて本当に濫用されたように見えるわれわれの神秘的な金属のボックスを残す。 4.9.7.1 階層化テクスチャの宣言 我々のシーンの中でいくつかのオブジェクト上に階層化されたテクスチャを再利用したい出来事で、階層化されたテクスチャを宣言することは全く正当である。我々は上記から全部のテクスチャを繰り返さないだろう。しかし、全般的なフォーマットは何かこのようなものである： #declare Abused_Metal = texture { /* 基礎テクスチャをここに挿入... */ } texture { /* 錆のまだらをここに... */ } texture { /* もちろん、すすけたやけどマークはここ */ } POV-Rayはどこで宣言が終わるかを指示する問題はない。なぜなら、テクスチャがオブジェクトも命令も間になく代わる代わる続くからである。宣言される階層化テクスチャは別のテクスチャ以外の何かまで続くものと仮定される。したがって任意の数の層をこの様式の宣言に加えることができる。 階層化されたテクスチャについての一つの最終的な言葉:我々が作成したどんな階層化テクスチャでも、宣言されるかどうかに関わらず、テクスチャ包み(texture wrapper)をやめてはならない。慣習的な単一のテクスチャでの一般の短縮形は、ピグメントだけ、あるいはピグメントと仕上げだけ、あるいは法線だけ、あるいはなにかを持つことであり、それらをテクスチャ文の外側に残しておくことである。この短縮形は階層化テクスチャには拡張されない。POV-Rayに関わる限り、我々は、テクスチャの個々の部分以外の全体のテクスチャを階層化することができない。例えば #declare Bad_Texture = texture { /* ここに基礎テクスチャを挿入せよ... */ } pigment { Red filter .5 } normal { bumps 1 } はうまく働かない。そのピグメントと法線は任意の特定のテクスチャの一部分にならずにただそこに浮くだけである。オブジェクトの内側では、単一のテクスチャだけで、この類のことができるが、階層化テクスチャではオブジェクトの内側でも宣言の中であるにせよエラーを生むだけである。 4.9.7.2 他の階層化テクスチャの例 さらに、階層化されたテクスチャがどのように働くか説明するために、別の例が、詳細に解説される。テーブルクロスは、ピクニックシーンで用いられるために作成される。単純な赤と白のチェックの布はあまりに完全に新しく、あまりに平らで、あまりにタイルを張られた床のように見えるから、階層化されたテクスチャが、布にしみをつけるために用いられる。 我々は、4つのボックスを含んでいるシーンを作成しようとしている。最初のボックスはわれわれのピクニックシーンを始めた単調な赤と白のテクスチャを持ち、2番目に現実的に布をしおれさせることを意味する層を加え、三番目はワインのしみを加え、そして最後のボックスはいくらかのしわを加える(別の層ではないが、階層化テクスチャで表面法線が効果を持つためにいつどこで変更を加えるかに注意しなければならない)。 われわれはカメラ、いくつかのライト、および最初のボックスを置くことから始めた。この段階では、テクスチャは単調なタイリングであり、階層化ではない。ファイルlayered1.povを見て欲しい。 #include "colors.inc" camera { location <0, 0, -6> look_at <0, 0, 0> } light_source { <-20, 30, -100> color White } light_source { <10, 30, -10> color White } light_source { <0, 30, 10> color White } #declare PLAIN_TEXTURE = // 赤/白 チェック texture { pigment { checker color rgb<1.000, 0.000, 0.000> color rgb<1.000, 1.000, 1.000> scale <0.2500, 0.2500, 0.2500> } } // 単調な赤/白 チェックのボックス box { <-1, -1, -1>, <1, 1, 1> texture { PLAIN_TEXTURE } translate <-1.5, 1.2, 0> } このシーンをレンダリングする。これは特別に面白いわけではないね。そうでしょう? それがわれわれが階層化テクスチャを使ってもっと面白くしようという理由である。 最初に、2つの異なる、部分的に透明な灰色の層を加える。赤と白の色でタイル貼りしたようにそれらをタイル貼りするが、フェイディングをよりリアリスティックにするためにいくらかの動乱を加える。前のシーンに以下のボックスを加え、再レンダリングする(ファイルlayered2.pov参照)。 #declare FADED_TEXTURE = // 赤/白 チェックテクスチャ texture { pigment { checker color rgb<0.920, 0.000, 0.000> color rgb<1.000, 1.000, 1.000> scale <0.2500, 0.2500, 0.2500> } } // 赤/白をフェイドさせるグレイ texture { pigment { checker color rgbf<0.632, 0.612, 0.688, 0.698> color rgbf<0.420, 0.459, 0.520, 0.953> turbulence 0.500 scale <0.2500, 0.2500, 0.2500> } } // フェイドした赤/白のボックス box { <-1, -1, -1>, <1, 1, 1> texture { FADED_TEXTURE } translate <1.5, 1.2, 0> } たとえそれが微妙な差であるとしても、赤と白のチェックは、もはやそれほど完全に新しく見ない。 ピクニックシーンにはワインが一本あるので、一つ二つのしみを加えることは素晴らしいタッチになると思う。この効果は、ほとんど平らにされたブロブを布の上に置くことで成し遂げられるので、われわれが実際に終えるのはこぼれた効果であり、しみではない。従って他の層をつけ加える時である。 再び、我々は別のボックスを我々がすでに書いたシーンにつけ加え、再レンダリングする。ファイルlayered3.povを見なさい）。 #declare STAINED_TEXTURE = // 赤/白のチェック texture { pigment { checker color rgb<0.920, 0.000, 0.000> color rgb<1.000, 1.000, 1.000> scale <0.2500, 0.2500, 0.2500> } } // チェックをフェイドさせるグレイ texture { pigment { checker color rgbf<0.634, 0.612, 0.688, 0.698> color rgbf<0.421, 0.463, 0.518, 0.953> turbulence 0.500 scale <0.2500, 0.2500, 0.2500> } } // ワインのしみ texture { pigment { spotted color_map { [ 0.000 color rgb<0.483, 0.165, 0.165> ] [ 0.329 color rgbf<1.000, 1.000, 1.000, 1.000> ] [ 0.734 color rgbf<1.000, 1.000, 1.000, 1.000> ] [ 1.000 color rgb<0.483, 0.165, 0.165> ] } turbulence 0.500 frequency 1.500 } } // しみをつけられたボックス box { <-1, -1, -1>, <1, 1, 1> texture { STAINED_TEXTURE } translate <-1.5, -1.2, 0> } 今、個性をもったテーブルクロステクスチャがある。 我々が布に付け加えたい別のタッチは、まるで布がしわくちゃにされたようないくつかのしわである。これは別のテクスチャ層ではないが、階層化テクスチャで作業をしているとき、表面法線の変化はテクスチャの最上位の層に含めなければならないということを心にとどめておかなければならない。下位の層の変更は最終製品に影響を与えない(上位の層がどのように透明かは問題ではない)。 我々が、この最終的なボックスを原稿に付け加え再レンダリングする(ファイルlayered4.povを見なさい）。 #declare WRINKLED_TEXTURE = // 赤と白のチェック texture { pigment { checker color rgb<0.920, 0.000, 0.000> color rgb<1.000, 1.000, 1.000> scale <0.2500, 0.2500, 0.2500> } } // チェックを「薄く」するための灰色 texture { pigment { checker color rgbf<0.632, 0.612, 0.688, 0.698> color rgbf<0.420, 0.459, 0.520, 0.953> turbulence 0.500 scale <0.2500, 0.2500, 0.2500> } } // ワインのしみ texture { pigment { spotted color_map { [ 0.000 color rgb<0.483, 0.165, 0.165> ] [ 0.329 color rgbf<1.000, 1.000, 1.000, 1.000> ] [ 0.734 color rgbf<1.000, 1.000, 1.000, 1.000> ] [ 1.000 color rgb<0.483, 0.165, 0.165> ] } turbulence 0.500 frequency 1.500 } normal { wrinkles 5.0000 } } // しわになったボックス box { <-1, -1, -1>, <1, 1, 1> texture { WRINKLED_TEXTURE } translate <1.5, -1.2, 0> } さあ、これはわれわれが参加しているどのピクニックにも欲しくないテーブルクロスかも知れないが、最後のボックスを最初のと比べれば、創造的なテクスチャ付けの使用だけでどれくらいの深さ、大きさ、そして個性が可能かがわかるだろう。 最後の一つの注意:表面法線に関するコメントは仕上げ(finishes)に対してはあてはまらない。もし下位の層がspecular仕上げを持ち、上位の層がそうでなければ、上位の層が透明になる任意の場所で、specularが通して見えるだろう。 4.9.8 他のすべてが失敗したら:マテリアルマップ われわれはわれわれの処理において、かなりパワフルなテクスチャリングツールを持っているが、もし、より自由に複雑なテクスチャの配合を形づくるには何があるか？そう、イメージマップがピグメントに対してできるような、そしてバンプマップが法線に対してするような、すべてのテクスチャをマップする事ができるマテリアルマップ(material map)を用いる要求が生じるであろう。 イメージマップやバンプマップと同じように、ビットマップ形式のソースイメージが必要である。それは個々のテクスチャがどこに行くかのマップを供給するためにPOV-Rayから呼び出される。しかし今は、どのテクスチャがそのパレットインデックスと関連づけられるかを指定する必要がある。そのようなイメージを作るために、パレットインデックス番号で色を選択できるペイントプログラムを使うことができる(それはその位置にどのテクスチャが行くかをPOV-Rayに伝えるためのただのマップであるから実際の色は無関係である)。今、POV-Rayとともに来た完全なパッケージがあれば、インクルードファイルの中にpovmap.gifという名の画像がある。それはビットマップイメージで隣接する四角形とPersistance of Visionの単語を作るために最初の4つのパレットインデックスだけが使われている。これは以下の例のサンプルマップとしてちょうど良い。同じインクルードファイルとカメラ、光源を用いて以下のオブジェクトを入れよう。 plane { -z, 0 texture { material_map { gif "povmap.gif" interpolate 2 once texture { PinkAlabaster } // 内側の境界 texture { pigment { DMFDarkOak } } // 外側の境界 texture { Gold_Metal } // 文字 texture { Chrome_Metal } // ウィンドウパネル } translate <-0.5, -0.5, 0> scale 5 } } 光源の位置と反射させられるための前景のオブジェクトの欠如によって、それらのテクスチャを最善の長所で示せない。しかし、少なくともこの処理がどのように働くかは分かる。テクスチャは単純に特定のパレットインデックスのピクセルの位置に応じて配置される。(タイリングからそれを守るために)onceキーワードの使用と、使っているカメラに合わせるためのマップの平行移動とスケーリングによって、すべてが我々に対して広がって見えるようになる。 もちろん、それはGIFやある種のフレーバーのPNGのようなパレットマップされたイメージフォーマットのものであった。マテリアルマップはまたPOV-Rayが出力するTGAのような非パレットフォーマットも使うことができる。それは面白い結果を導く:POV-Rayのためのソースマップを作るためにPOV-Rayを使うことができる! 特殊テクスチャのいくらかの制限に没頭する前に、POV-Rayがどうやって自分自身のためのソースマップを作るかを見るためにマテリアルマップでもう一つのことをしてみよう。 まず最初に、非パレット形式のイメージを使っているならば、POV-Rayはリストからどのテクスチャを使うか決めるためにそのピクセルの色の赤成分を見る(それは0 から 255までの値であろう)。そこで、ソースマップを作成するために、我々は、与えられたピクセルの赤の値が何であるかをとても精密に制御する必要がある。それは以下のようにすればよい 1.)カラーを選択するためにrgb のような rgb 文を使い、 2.)光源を使わずにすべてのオブジェクトに仕上げfinish { ambient 1 }を適用し、ハイライティングとシャドウイングが口出ししないことを確実にする。 混乱するかい? いいだろう、ここに、われわれが初期に用いたpovmap.gifに、TGAフォーマットであること以外はとても良く似たマップを作成する例がある。ピグメントに青と緑の成分も与えたことを注意する。POV-Rayは最終的なマップでそれらを無視するので、これは実際は、肉眼では0と4/255の赤の変動の間の差に気が付かない我々人間のためのものである。これらの青と緑の変動無しでは、マップは我々の目には同一調の黒いスクリーンの様に見える。これはPOV-Rayを用いた秘密のメッセージを送るすばらしい方法である(解読するにはそれをマテリアルマップに作用させなさい)が、もしわれわれの期待通りかどうかを確認するためにソースマップがどのように見えるかを見たいのならば意味がない。 以下のコードをレンダリングし、結果のファイルをpovmap.tgaと名付ける。 camera { orthographic up <0, 5, 0> right <5, 0, 0> location <0, 0, -25> look_at <0, 0, 0> } plane { -z, 0 pigment { rgb <1/255, 0, 0.5> } finish { ambient 1 } } box { <-2.3, -1.8, -0.2>, <2.3, 1.8, -0.2> pigment { rgb <0/255, 0, 1> } finish { ambient 1 } } box { <-1.95, -1.3, -0.4>, <1.95, 1.3, -0.3> pigment { rgb <2/255, 0.5, 0.5> } finish { ambient 1 } } text { ttf "crystal.ttf", "The vision", 0.1, 0 scale <0.7, 1, 1> translate <-1.8, 0.25, -0.5> pigment { rgb <3/255, 1, 1> } finish { ambient 1 } } text { ttf "crystal.ttf", "Persists!", 0.1, 0 scale <0.7, 1, 1> translate <-1.5, -1, -0.5> pigment { rgb <3/255, 1, 1> } finish { ambient 1 } } われわれがしなければならないことは、マテリアルマップをGIFからTGAに変えて、ファイル名を変更して、最終的なマテリアルマップの例を変更することである。この新しいマップを用いてレンダリングすると、他のペイントプログラムを用いなくても良いことを除いて以前に用いたパレットマップされたGIFときわめて類似している: POV-Rayですべてできた! 4.9.9 特殊テクスチャの制限 (テクスチャ、ピグメントおよび法線マップからマテリアルマップまでの)我々が見たすべての特殊テクスチャに対して2つの制限がある。第一は、シーンの中のすべての項目に対してデフォルトテクスチャを設定するためのdefault命令を用いると、ここで議論した特殊テクスチャのどれもが受け入れられなくなる。我々は常にそのようなテクスチャを宣言することができて、個別にそれをすべてのオブジェクトに適用することができるので、これは実際にはとても少数のことである。実際には別の方法ではできないことは何をすることも妨げられない。 もう一つはより大きな制限であるが、すぐに示すように、とても容易に働かすことができる。われわれが階層化テクスチャを用いた作業をしてたとき、既にどのようにして複数のテクスチャを他の上に積み重ねるかを見た(その中で少なくとも一つのテクスチャは透明性を持たなければならない)。このとても便利なテクニックは一つの層として見た特殊テクスチャに含まれる問題を持つ。しかし解決策がある! 例えば、銀のメタリックな表面を持つSpeckled_Metalと呼ばれる階層化テクスチャがあるとしよう。そこに全体にわたって小さい錆のしみを置く。そして実際にさびた外観のために、我々は、表面上の集中した錆のパッチをランダムに作成したいと決意する。明白なアプローチは、最上層で使うための透明度を持つ特殊なテクスチャパターンを作成することである。しかしもちろん、既に見たように、層としてそのようなテクスチャパターンは使えない。エラーメッセージが生ずるだけである。解決策は内側の問題を外側に変え、代わりにその階層化テクスチャの部分を以下のように作ることである // この部分は錆パッチテクスチャパターン // で使うためのテクスチャを宣言する #declare Rusty = pigment { granite color_map { [ 0 rgb <0.2, 0, 0> ] [ 1 Brown ] } frequency 20 } // そしてこの部分はそれに適用される // 注意:我々のオリジナルの階層化テクスチャ // "Speckled_Metal"は今、マップの一部分になる #declare Rust_Patches = texture { bozo texture_map { [ 0.0 pigment {Rusty} ] [ 0.75 Speckled_Metal ] [ 1.0 Speckled_Metal ] } } そして、最終的な効果はいずれにしろ小斑点のある錆のパッチを階層化したのと同じである。 パターン、ピグメント、法線、仕上げ、階層化および特殊テクスチャの完全な配列により、驚くべきテクスチャの方法で、我々が作成できないものは特になにも無い。ほとんど無限の数の新しい可能性が、まさに作成されるために待っている！ 4.10 大気の効果を使用する POV-Rayは、いろいろな大気の効果(Atmospheric Effects)、すなわちシーンの背景に影響を及ぼすフィーチャーやすべてを包む大気を提供する。 単純な色や複雑なカラーパターンを仮想天球(sky sphere)に割り当てることは簡単である。あなたは、雲から、青い夏の空から嵐の重く曇った空までどんなものも自由につくることができる。星のフィールドも簡単につくることができる。 あなたは、霧のかかったシーンをつくるために別の種類のフォグ(fog:霧)を使用することができる。色の異なる複数の霧層は、不気味なタッチをあなたのシーンに加える。 より多くの非常に現実的な効果を、光源から来る光と相互に作用するコンスタントフォグを使用することによって作ることができる。光のビームは見えるようになり、オブジェクトは霧に影を投げかける。 4.10.1 背景(Background) 背景(background)フィーチャーは、オブジェクトにぶつからないすべての光線に色を割り当てるために使用される。これは以下の方法で可能である。 camera { location <0, 0, -10> look_at <0, 0, 0> } background { color rgb <0.2, 0.2, 0.3> } sphere { 0, 1 pigment { color rgb <0.8, 0.5, 0.2> } } もし天球が使われ、すべての天球のピグメント層(pigment layers)が処理された後、半透明性が残っている場合、背景色(background color)が見える。 4.10.2 天球(Sky Sphere) 天球(sky sphere)は雲に覆われた空や、星の夜の空、あるいはあなたの心の中の空を何でも簡単に作るために用いられる。 以下の例では非常に簡単な天球(sky sphere)から始め、だんだんと複雑な新しいフィーチャーを加えて行く。 4.10.2.1 色勾配(Color Gradient)によって空をつくる 背景(background)フィーチャーでおおわれている一つの色の天球で、最も単純な天球は色勾配である。 あなたは、空の色が地球の表面法線に対する角によって変化することに、気づいただろう。 あなたが空を見上げる時、真上を見るときの方が水平線方向を見るときよりもより深い青に見えるだろう。 われわれは天球(sky sphere)を用いてこの効果を以下の例で示すようにモデル化したい( skysph1.pov )。 #include "colors.inc" camera { location <0, 1, -4> look_at <0, 2, 0> angle 82 } light_source { <10, 10, -10> White } sphere { 2*y, 1 pigment { color rgb <1, 1, 1> } finish { ambient 0.2 diffuse 0 reflection 0.6 } } sky_sphere { pigment { gradient y color_map { [0 color Red] [1 color Blue] } scale 2 translate -1 } } 面白い部分は、sky sphere構文である。それは、天球の外観を記述するピグメントを含む。我々は、地球の表面法線に対して測定された視角に沿って色勾配をつくりたい。光線方向ベクトルがピグメントカラーを計算するために使用されたので、我々はy-勾配(y-gradient)を使用しなければならない。 スケール、および平行移動変換は、方向ベクトルから正しい範囲まで誘導された点をマップするために使用される。それらの変換なしではパターンは、二度天球の上で繰り返される。scale構文は反復をさけるために用いられる、translate -1 構文はインデックス0の色を天球の最下部へ移動させる(あなたがまっすぐ見おろしたときにあなたが見る天球の点である)。 この変換の後、位置0のカラーエントリは天球の底、つまり、我々の下になり、カラーポジション1は頂上、つまりわれわれの真上になる。 あなたが結果として生ずるイメージで見るように、すべての他の位置の色は、それらの2つの色の間に補間される。 図　単純な勾配を持つ天球。 あなたが特定の角度の色から始めたいならば、あなたは最初に角度をカラーマップインデックスに変換しなければならない。これは、以下の公式を使用することによってなされる。 color_map_index = (1 - cos(angle)) / 2 ここで、角度は、負方向の地球の表面法線に対して測定される。これは、地球の中心の方を示している表面法線である。180度の角度は天頂を表現し、0度の角度は、我々の下の点を記述する。 下記の例で示されるように、POV-Rayの中であなたは、最初に角度値をラジアン値に変換しなければならない。 sky_sphere { pigment { gradient y color_map { [(1-cos(radians( 30)))/2 color Red] [(1-cos(radians(120)))/2 color Blue] } scale 2 translate -1 } } このシーンは、30度で赤いカラーから始め、そして、それは120度まで青いカラーに混じり合うカラー勾配を使用する。120度より上ではすべてが青く、30度の以下ではすべてが赤い。 4.10.2.2 太陽を加える 下記の例で我々は、ダークブルーの夜空に融合する赤いカラーハローによって囲まれた赤い太陽のある空をつくる。我々は、それをこの天球(sky sphere)フィーチャーだけを使用することによって行う。 我々が使用する天球(sky sphere)は、下で示される。また、地上平面は、よりすばらしいリアリズムのために加えられる(skysph2.pov)。 sky_sphere { pigment { gradient y color_map { [0.000 0.002 color rgb <1.0, 0.2, 0.0> color rgb <1.0, 0.2, 0.0>] [0.002 0.200 color rgb <0.8, 0.1, 0.0> color rgb <0.2, 0.2, 0.3>] } scale 2 translate -1 } rotate -135*x } plane { y, 0 pigment { color Green } finish { ambient.3 diffuse.7 } } pigmentの内側のgradientパターンと変換は、以前のセクションの中での例と同じものである。 カラーマップは、3つのカラーから成る。太陽のために使用される明るい、わずかに黄色がかった赤、ハローのためのより暗い赤と夜空のためのダークブルーである。我々は太陽にあまりに大きくなって欲しくないので、太陽のカラーは、天球の非常に小さい部分だけをカバーする。カラーは、カラーマップ値0.000と0.002で値0.002で鋭いコントラストを得るために使用される(我々は太陽が空に融合して欲しくない)。ハローのために使用されたより暗い赤い色は、値0.002から0.200までダークブルーの空色に融合する。0.200より上のすべての値は、ダークブルーの空を表す。 rotate -135*x 構文は太陽とできあがった天球を最終的な位置まで回転する。この rotation がないと太陽は 0度(つまりわれわれの右側)に位置する。 図　赤い太陽が夜の中に沈む。 結果として生ずるイメージを見ると、あなたは、あなたが天球(sky sphere)でどんな感動的な効果を成し遂げることができるかわかる。 4.10.2.3 雲を加える さらに我々のイメージを改善するために、我々は第2のピグメント(pigment)を加えることによって雲を加えたい。この新しいpigmentは、素晴らしい雲をつくるためにbozoパターンを使用する。それがもう一方のピグメントのトップに横たわるから、それは、カラーマップ(エントリ0.5〜1.0を見ること)の中で半透明のカラーを必要とする。 sky_sphere { pigment { gradient y color_map { [0.000 0.002 color rgb <1.0, 0.2, 0.0> color rgb <1.0, 0.2, 0.0>] [0.002 0.200 color rgb <0.8, 0.1, 0.0> color rgb <0.2, 0.2, 0.3>] } scale 2 translate -1 } pigment { bozo turbulence 0.65 octaves 6 omega 0.7 lambda 2 color_map { [0.0 0.1 color rgb <0.85, 0.85, 0.85> color rgb <0.75, 0.75, 0.75>] [0.1 0.5 color rgb <0.75, 0.75, 0.75> color rgbt <1, 1, 1, 1>] [0.5 1.0 color rgbt <1, 1, 1, 1> color rgbt <1, 1, 1, 1>] } scale <0.2, 0.5, 0.2> } rotate -135*x } 図　太陽をセットした曇り空。 あなたが最終イメージ( skysph3.pov )を見ているときに気がつくように、この天球は一つの欠点を持つ。太陽は光を発しない、そして、雲は影を投げない。あなたが影を投げた雲が欲しいのならば、あなたはリアルな大きな球を、該当するテクスチャと球の外側の光源とともに用いなければならない。 4.10.3 フォグ(Fog) あなたは、2つの異なる型のフォグ(霧)をあなたのシーンに加えるためにfogフィーチャーを使用することができる:コンスタントフォグ(constant fog)とグランドフォグ (ground fog)である。 コンスタントフォグは至る所一定密度の霧で、グランドフォグの密度はあなたが上に行くほど減少する。 両タイプのフォグの使用法は以下のセクションで詳しく述べる。 4.10.3.1 コンスタントフォグ 最も簡単なタイプのフォグはコンスタントフォグである。これはすべての場所で一定密度である。これはフォグの密度とフォグのカラーを実際に記述するdistanceキーワードで指定される。 distance値は36.8%背景が見える距離を定める(どのようにフォグが計算されるかのより詳しい説明はリファレンスセクションの「フォグ」を読んで欲しい )。 フォグの色は純白から血のような赤いフォグまでどんなものを作るためにも使うことができる。また、あなたは限られた範囲の視野の効果をシミュレートするために黒いフォグを使用することができる。 以下の例は、どのようにフォグを単純なシーン(fog1.pov)に加えるか、あなたに示す。 #include "colors.inc" camera { location <0, 20, -100> } background { colour SkyBlue } plane { y, -10 pigment { checker colour Yellow colour Green scale 20 } } sphere { <0, 25, 0>, 40 pigment { Red } finish { phong 1.0 phong_size 20 } } sphere { <-100, 150, 200>, 20 pigment { Green } finish { phong 1.0 phong_size 20 } } sphere { <100, 25, 100>, 30 pigment { Blue } finish { phong 1.0 phong_size 20 } } light_source { <100, 120, 40> colour White} fog { distance 150 colour rgb<0.3, 0.5, 0.2> } 図　霧のかかったシーン。 このdistanceにより、このシーンの中の球はチェッカーボード平面と同様、多かれ少なかれ我々が使用した緑がかった霧に消える。 4.10.3.2 最小の半透明性をセットする あなたが、背景が完全に霧に消えないかどうか確かめたいのならば、あなたは、霧のカラーの透過率チャネルで、あなたが常に見えて欲しい背景の量を調整することができる。 透過率値0.2を以下のように使う fog { distance 150 colour rgbt<0.3, 0.5, 0.2, 0.2> } あなたが結果として生ずるイメージ(fog2.pov)で見ることができるように、フォグの半透明性は、20 %以下には決して落ちない。 図　半透明性のしきい値(translucency threshold)を加えても背景は消えないことが確認できる。 4.10.3.3 フィルタリングフォグ(Filtering Fog)を作る 我々が今までのところ使用した緑がかった霧は、それを通り抜けている光をフィルタリングしない。すべての光の強度を減らすことになっている。我々は、フォグのカラー(fog3.pov)の中で非0フィルタチャネルを使用することによってこれを変えることができる。 fog { distance 150 colour rgbf<0.3, 0.5, 0.2, 1.0> } フィルタ値は、フォグによってフィルタリングされる光の量を決定する。我々の例の中で霧を通り抜けている光の100 %は、霧によってフィルタリングされる。我々が0.7の値を使用したならば、光の70 %はフィルタリングされた。残る30 %がフィルタリングされずに通過した。 図　フィルタリングした霧(A filtering fog)。 あなたは、フォグの中のオブジェクトの強度が、フォグの色のために減らされるだけでなく、フォグによって色が実際に影響されることに気がつくだろう。赤と特に青い球は緑の色合いを得た。 4.10.3.4 フォグに動乱を加える 我々のいくぶん退屈な霧を少しより面白く作成するために、非一定密度(fog4.pov)を持つように見えさせるために我々は動乱(turbulence)を加えることができる。 fog { distance 150 colour rgbf<0.3, 0.5, 0.2, 1.0> turbulence 0.2 turb_depth 0.3 } 図　霧に動乱を加えるともっと面白くなる。 turbulenceキーワードは、使用される動乱の量を指定するために使われ、turb_depth値はturbulence値が視線光線に沿って計算された点を移動させるために用いられる。ゼロに近い値は、点をビューアーの方へ動かし、1に近い値はそれを交差点(デフォルト値は0.5である)の方へ動かす。このパラメータは、turbulenceのためにフォグに現れるだろうノイズを避けるために使用することができる(これは通常非常に遠い交差点で起こる。特に、交差が起きない場合は背景にヒットする時)。この場合は、ノイズがなくなるまで低いturve_depthを使う。 実際のフォグの密度は変化しないことを心にとどめておくべきである。フォグの距離に基づく減衰値だけが、turbulence値によって視線光線に沿った点で修正される。 4.10.3.5 グラウンドフォグを使う 非常により多くの面白くて柔軟なフォグのタイプは、fog_type構文で選ばれるグラウンドフォグ(Ground Fog:地上霧)である。その外観は、fog_offsetとfog_altキーワードで記述される。fog_offsetが、高さ(すなわちy値)を指定する。それ以下ではフォグは一定の密度1である。fog_altキーワードは、y軸に沿って移動した場合に、フォグの密度がどれくらい速くゼロに近づくか決める。fog_offset+fog_altの高さでフォグは25 %の密度である。 以下の例(fog5.pov)は、グラウンドフォグを使用する。y=25以下では一定密度で(赤い球の中心)高度が増加するのに伴い急激に密度は落ちる。 fog { distance 150 colour rgbf<0.3, 0.5, 0.2, 1.0> fog_type 2 fog_offset 25 fog_alt 1 } 図 グラウンドフォグは低い部分だけを覆う。 4.10.3.6 複数層のフォグを使う あなたのシーンファイルの中に2つ以上のfog構文を用いることによりいくつかの層になったフォグを用いることが可能である。あなたが乱れた(turbulent)グランドフォグを使用している効果を素晴らしくしたいならば、これはとても便利である。例えば不気味なシーンを作るために色の付いた別のいくつかの霧を加えることができる。 では、以下の例を試してみよう( fog6.pov )。 fog { distance 150 colour rgb<0.3, 0.5, 0.2> fog_type 2 fog_offset 25 fog_alt 1 turbulence 0.1 turb_depth 0.2 } fog { distance 150 colour rgb<0.5, 0.1, 0.1> fog_type 2 fog_offset 15 fog_alt 4 turbulence 0.2 turb_depth 0.2 } fog { distance 150 colour rgb<0.1, 0.1, 0.6> fog_type 2 fog_offset 10 fog_alt 2 } 図　複数層の霧を使うと、とてもすばらしい結果を達成することができる。 あなたは、コンスタントフォグ、グラウンドフォグ、フィルタリングフォグ、ノンフィルタリングフォグ、半透明性のしきい値をもつフォグ、などを結合することができる。 4.10.3.7 フォグと中空(Hollow)オブジェクト あなたがフォグフィーチャーを使用し、カメラが中空でないオブジェクトにあるときはいつでも、あなたはフォグの効果を得ない。これが起こる理由の詳細な説明のために、「中空オブジェクトと中実オブジェクト(Empty and Solid Objects)」を見よ。 この問題をさけるためには、あなたはカメラがそれらのオブジェクトの外側にあることを確実にするか(inverseキーワードを使用する)か、あるいはそれらにhollowキーワードを付けることにより(この方が簡単)すべてのそれらのオブジェクトを中空にしなけらばならない。 4.10.4 大気(Atmosphere) 重要な注意:POV-Ray 3.0の大気の機能はいくぶん実験的なものである。これらの機能の設計とインプリメンテーション(実現)は将来のバージョンで変更される可能性が高い。我々は、3.0でこれらの機能を用いているシーンが、今後のリリースで同じくレンダリングできるか、あるいは言語構文の後ろ向き互換性を完全に維持することができるかどうかを約束することができない。 大気(atmosphere)フィーチャーは、空気中の粒子と光の相互作用をモデル化するために使用することができる。光の光線は見えるようになる、そして、空気を満たしている霧やほこりにオブジェクトは影を投げる。 POV-Rayの中で使用された大気モデルは、ソリッドオブジェクトを除いた至る所に一定の粒子密度を仮定する。あなたが霧か煙のような雲を作りたいならば、あなたはセクション「ハロー」の中で記述されたハロー テクスチャリングフィーチャーを使用しなければならない。 4.10.4.1 何もない部屋から始める 我々は、大気フィーチャーがどのように働くかと、あなたがどのように良い結果を得るか説明するために単純なシーンをつくりたい。 窓のある単純な部屋を想像しなさい。光は、窓を通して落ちて、ほこりの粒子によって空気中に散乱させられる。あなたは、窓から来て、床に照っている光のビームを見る。 我々は、一歩一歩このシーンをモデル化したい。以下の例は、部屋、窓、部屋の外側のどこかにあるスポットライトから始める。現在，照明が正しいことを確認するため大気はない。(atmos1.pov )。 camera { location <-10, 8, -19> look_at <0, 5, 0> angle 82 } background { color rgb <0.2, 0.4, 0.8> } light_source { <0, 19, 0> color rgb 0.5 atmosphere off } light_source { <40, 25, 0> color rgb <1, 1, 1> spotlight point_at <0, 5, 0> radius 20 falloff 20 atmospheric_attenuation on } union { difference { box { <-21, -1, -21>, <21, 21, 21> } box { <-20, 0, -20>, <20, 20, 20> } box { <19.9, 5, -3>, <21.1, 15, 3> } } box { <20, 5, -0.25>, <21, 15, 0.25> } box { <20, 9.775, -3>, <21, 10.25, 3> } pigment { color red 1 green 1 blue 1 } finish { ambient 0.2 diffuse 0.5 } } 図　我々が始めたい何もない部屋 点光源は、大気との相互作用なしで内部から部屋を明るくするために使用される。これは、atmosphere offを加えることによってされる。この光については後にatomosphereを加えるまでは心配しなくて良い。 スポットライトは、atmospheric_attenuationキーワードとともに使用される。これが、スポットライトから届いている光が、大気によって減らされることを意味する。 結合オブジェクトは、部屋と窓をモデル化するために使用される。我々はこの部屋をモデル化するために2つのボックスの間の差を使用する(difference構文の中の最初の2つのボックス)ので結合に hollowをセットする必要はない。我々がこの部屋にいるならば、我々はオブジェクトの外側に実際は居る(また、「Hollowオブジェクトと大気を使う」を見なさい)。 4.10.4.2 部屋にダストを加える 次のステップは、大気(atmosphere)を部屋に加えることである。これは、以下の少しの行によってなされる(atmos2.pov)。 atmosphere { type 1 samples 10 distance 40 scattering 0.2 } typeキーワードは、我々が使用したい大気の散乱の型を選ぶ。ここでは、われわれは等しくすべての方向に光を散乱させる等方的な散乱を用いる(様々な散乱型についてより多くの詳細は「大気(atmosphere)」を見なさい)。 samplesキーワードは、大気の効果を累積する際に使用されるサンプルの数を決める。あらゆる光線に対して、サンプルが光源で照明されているかどうか決めるために光線に沿ってサンプルはとられる。サンプルが照らされるならば、観察者の方向に散乱させられる光の量が決められて、全体の強度に加えられる。 常に、あなたは任意の数のサンプルから始めることができる。結果があなたの考えに合わないならば、あなたは結果をより良くするためにサンプリング率を増やすことができる。良いサンプリング率を選ぶ問題は、満足なイメージと速いレンダリングの間のトレードオフである。ほとんど常に、高いサンプリング率は機能する。しかし、また、レンダリングは非常に長い時間かかる。これは実験すべきことである。 distanceキーワードは、大気の密度を指定する。それは、フォグフィーチャーのdistanceパラメータと同じ方法で働く。 最後の最小でないscattering(散乱)値は粒子によって散乱させされる光の量を決める(残りの光は吸収される)。あなたが後にわかるように、このパラメータは、大気の総体的な明るさを調節する際に非常に便利である。 図　ダストを加えると光のビームが見えるようになる。 上のシーンでつくられたイメージを見ると、マッハバンド(Mach-bands)として知られている非常に醜いアンチエイリアスアーチファクトに気がつくだろう。それらは、低いサンプリング率の結果である。 4.10.4.3 良いサンプリング率の選択 あなた見たように、あまりに低いサンプリング率は醜い結果を引き起こす。それらの問題を減じるか避ける方法がある。 力ずくのアプローチは、アーチファクトが消え、あなたが満足なイメージを得るまでサンプリング率を増やすことである。常に、これは働くけれども、それが非常に時間がかかるので、これは悪い考えである。より良いアプローチは、最初にジッタリングとアンチエイリアシングを使用することである。この両方のフィーチャーが手助けにならないならばあなたは、サンプリング率を増やさなければならない。 ジッタリング(jittering:踊り)は、小さい、ランダムな量によって、サンプリング方向に沿って各々のサンプル点を動かす。これは、エイリアシングから生じている規則的なフィーチャーを減らすのを助ける。低いサンプリング率から起こっている規則的なフィーチャーほど人間の視覚のシステムに対していらいらさせるものは(ほとんど)ない。サンプリングポイントをジッタリングさせることによりイメージに余分なノイズを加えることはより良いことである。人間の目はより多くそれを許容する。 jitterキーワードとそれに続くあなたが使用したいジッタリングの量を使用しなさい。良いジッタリング値は最高0.5である、より高い値はあまりにたくさんのノイズになる。 あまりに低いサンプリング率より生じたアーチファクトはジッタリングで修正することができないことをあなたは知っていなければならない。それは醜くさを増すだけである。 エイリアシングしているアーチファクトを減らす他のより良い方法は、(補助的な)スーパーサンプリングを使用することである。この方法はそれが必要そうな付加的なサンプルを投げかける。2つの隣接したサンプルの間の強度があまりに多く違う場合、追加のサンプルが中間にとられる。このステップが指定された再帰レベルに達するか、サンプルが互いに隣接するまで再帰的になされる。 aa_levelとaa_thresholdキーワードは、スーパーサンプリングを制御するために使用される。aa_thresholdキーワードが2つのサンプルの間に許される最大の差を指定し、aa_levelキーワードは、最大再帰レベルをスーパーサンプリングがされる前に決める。 すべてのこの理論の後、我々は、我々のサンプルシーンに戻り、ジッタリングとスーパーサンプリングを使用するために該当するキーワードを加える(atmos3.pov)。 atmosphere { type 1 samples 50 distance 40 scattering 0.2 aa_level 4 aa_threshold 0.1 jitter 0.2 } 非常に低いスーパーサンプルのしきい値が、隣接の点の間の非常に類似した強度に対して選ばれた。最大再帰レベル4は、スーパーサンプルの最大数を15に導く。 あなたがジッタリングを加えて、スーパーサンプリングした後に得る結果を見ても、あなたは満足していないだろう。まだ見えるアーチファクトを減らす唯一の方法は、高いサンプル数(samples)を選ぶことによってサンプリング率を増やすことである。 図　高いサンプリング率は満足なイメージを導く。 これによりあなたはアーチファクトの(ほとんど)見えない良い結果を得る。ところで。この部屋のまわりに浮いているダストの量は少し過大に見えるだろう、しかし、それは例としてである。そして、例は誇張される傾向がある。 4.10.4.4 色付きの大気を使う あなたは、大気の外観に、より多くのコントロールを与えるカラーを大気に割り当てることができる。すべてのカラーは第一に、光源から来る光か、反射あるいは屈折した光あるいは背景からの光、それを通り抜けているすべての光をフィルタリングするために使用される。通り過ぎる光が大気のカラーによってフィルタリングされる量は、カラーのフィルタ値によって決められる。0の値は、光が、大気のカラーによって影響されないことを意味し、1の値は、すべての光が、カラーによってフィルタリングされることを意味する。 あなたが例えば赤らんだ大気をつくりたいならば、あなたは、上記の例の中で使用されたatmosphere構文に以下の行を加えることができる。 color rgbf <1, 0, 0, 0.25> rgb <1,0,0>を使用することは、カラーのフィルタ値がゼロであるので、有効でない。そして、光がカラーによってフィルタリングされない。すなわち、光はカラーのRGB成分で乗じられない。 0.25のフィルタ値は、大気を通り抜けている光の25 %が、赤いカラーによってフィルタリングされて、75 %フィルタリングされずに通過することを意味する。 大気のカラーの透過率チャネルは、最小限の半透明性(translucency)を指定するために使用される。デフォルトで、透過率チャネルはゼロであって、したがって、そのような最小限の半透明性はない。正の値を使用することは、あなたにdistanceキーワードによってセットされたその厚さに関係なく常に大気を通り抜ける背景光の量を決めさせせる。 あなたが例えば我々の部屋の例でrgbt <0,0,0,0.3>のカラーを使用するならば、あなたは青い背景を見えるようにすることができる。今までそれは、大気で隠れていた。 4.10.4.5 大気についての助言 大気フィーチャーを使用しているとき、満足な結果を得ることは非常に難しい。それらの中のより一般的な問題を解くための手助けは次のセクションで議論される(また、「Atmosphere Questions」セクションの中の大気についてのFAQセクションを見なさい)。 4.10.4.5.1 Distance および Scattering パラメータの選択 最初の難しいステップは、良いdistance(距離)とscattering(散乱)値を選ぶことである。あなたは、シーンと大気効果の中のオブジェクトの見える程度(視界)を制御することができることを必要とする。 最高のアプローチは、最初にdistance値を選ぶことである。この値は、大気による光の散乱にかかわらないシーンの中のオブジェクトの視界を決める。それは、フォグ(fog)フィーチャーのdistance値と同じ方法で働く。 フォグが照明されない(unlit)大気に非常に類似しているから、あなたはす速くworking distance値を選ぶために大気の代わりにフォグを使用することができる。我々が以前に使用した部屋のシーンで、あなたがこれをするならば、あなたはatmosphereの代わりに以下のfog構文を使用する(atmos4.pov)。 fog { distance 40 color rgb <0, 0, 0> } 図　黒いフォグは大気の働く距離(working distance)の値を得るために使うことができる。 黒いカラーは、影に横たわっている大気シーンのそれらの部分の中で、あなたが得る減衰をシミュレートするために使用される。 有色の大気を使用したいならば、フォグのために、フィルタと透過率チャネル値を含む大気のために使用したいのと同じカラーを使用しなければならない(大気のカラーの説明は「着色した大気」と「大気を使用する」を見なさい)。 (手荒く)光源で照らされるそれらの部分の外観をシミュレートしたいならば、フォグ構文の内側にその代わりに大気のカラーを使用することができる。 distance値に満足したら、scattering値を選ばなければならない。この値は、大気の強度をあなたの要求に合わせさせる。1の値で始めて、大気効果がほとんど見えないならば、値を増やさなければならない。大気の照らされた部分の中で、何も見えないならば、値を減少させなければならない。 あなたが求める結果を得るためには、非常に小さいか、非常に大きい値を使用しなければならないかもしれない、ということをあなたは知っていなければならない。 4.10.4.5.2 大気と光源 最高の結果は、スポットライトと円筒形の光源で生成される。それらは、光の素晴らしいビームをつくる。そして、それらはスポットライトの光円錐か円筒形の光の光円筒の内側の場所だけの大気の(atmospheric)サンプリングをするのでレンダリングが速い。 大気によって影響し合わない光源を加えたいならば、あなたはlight source構文の内側にatmosphereキーワードを使用することができる(「大気の相互作用」を見なさい)。atmosphere offを付け加えなさい。 デフォルトで、光源から届いている光は、大気によって減らされない。それで、あなたのシーンの中のハイライトは、通常あまりに明るい。これは、atmospheric_attenuationで変えることができる。 4.10.4.5.3 大気の散乱型 "大気"にリストされた異なる散乱型を、異なる種類の粒子をモデル化するために使用することができる。これは実験すべき事である。 ミー(Mie)散乱はフォグのために使用され、レイリー(Rayleigh)散乱は、小さいほこりのような粒子と煙のために使用される。 あなたが映画Casperの中で灯台シーンを見たことがあるならば、散乱型がどんな効果を持つか知っているだろう。このシーンの中で灯台から届いている光のビームは、それが観察者の近くの方を指す間見えるようになる。それが観察者から離れた方向を指し始めるとそれは消える。ミー散乱によってモデル化されるように、この動作は、微小な水滴に対して代表的なものである。 4.10.4.5.4 イメージの解像度を増す イメージの解像度を増やす場合、大気のサンプリング率を増やさなければならないかもしれないということを知っていなければならない。さもなければ、より低い解像度では、もはや見えなかったエイリアシングしているアーチファクトが、見えるようになるだろう。 4.10.4.5.5 Hollow(中空)オブジェクトと大気を使う 大気フィーチャーを使用するときはいつでも、大気で満たされるべきすべてのオブジェクトがhollowキーワードを使用して中空にセットされていることを確かめなければならない。 たとえこれが明らかでないとしても、これは無限の、そして、2次関数のようなパッチオブジェクト、4次多項式、三角形、多角形、などにあてはまる。それらのオブジェクトの一つを加えるときはいつでも、絶対にそれを必要としないと確信しない限り、あなたはhollowキーワードを加えなければならない。カメラがあるすべてのオブジェクトがhollowにセットされていることもあなたは確かめなければならない。 あなたが意外な結果を得るときはいつでも、あなたはソリッドオブジェクトについて調べ、それらをhollowにセットしなければならない。 4.10.5 虹(The Rainbow) 虹(rainbow)フィーチャーは、虹とおそらく他のより不思議な効果をつくるために使用することができる。虹は、コーンのようなボリュームに制限されるフォグのような効果である。 4.10.5.1 単純な虹から始める 虹は、たくさんのパラメータで指定される:それが見える角度、カラーバンドの幅、入射光の方向、フォグのようなdistanceをベースにした粒子密度、最後に重要な使用するカラーマップ。 虹のサイズと形は、angle(角度)とwidth(幅)キーワードによって決められる。direction(方向)キーワードは、入って来る光の方向をセットするために使用される。それで、虹の位置をセットする。方向ベクトルと光の入射方向の間の角度がangle-width/2より大きくてangle+width/2より小さいとき、虹は見える。 入射光(incoming light)は、虹の原因となる仮想光源である。虹効果をつくるために本当の光源は必要でない。 虹は、フォグのような(fog-like)効果、つまり虹の色は交差点の距離に基づき背景カラーで調合されたものである。あなたが小さいdistance値を選ぶならば、虹は、オブジェクトの上に見え、背景では見えない。非常に大きいdistance値を使用することによってこれを避けることができる。 カラーマップは、虹の中で通常見えるすべてのカラーを含んでいるから、虹の重要な部分である。一番外側のバンドがエントリ1からとられ、一番内側のカラーバンドのカラーは、カラーマップエントリ0からとられる。限られたカラー範囲のため、いかなるモニターでもリアルな虹を作ることは不可能であることに注意しなければならない。表示できない色がいくつかある。 虹のカラーマップのフィルタチャネルは、フォグと同じ方法で同様に使用される。それは、カラーによってフィルタリングして、どれくらい多くの光が虹を通り抜けるか決める。 以下の例は、地上平面と3つの球といくぶん誇張された虹で単純なシーンを示す(rainbow1.pov)。 #include "colors.inc" camera { location <0, 20, -100> look_at <0, 25, 0> angle 82 } background { color SkyBlue } plane { y, -10 pigment { colour Green } } light_source {<100, 120, 40> colour White} // 虹の色を宣言する #declare r_violet1 = colour rgbf<1.0, 0.5, 1.0, 1.0> #declare r_violet2 = colour rgbf<1.0, 0.5, 1.0, 0.8> #declare r_indigo = colour rgbf<0.5, 0.5, 1.0, 0.8> #declare r_blue = colour rgbf<0.2, 0.2, 1.0, 0.8> #declare r_cyan = colour rgbf<0.2, 1.0, 1.0, 0.8> #declare r_green = colour rgbf<0.2, 1.0, 0.2, 0.8> #declare r_yellow = colour rgbf<1.0, 1.0, 0.2, 0.8> #declare r_orange = colour rgbf<1.0, 0.5, 0.2, 0.8> #declare r_red1 = colour rgbf<1.0, 0.2, 0.2, 0.8> #declare r_red2 = colour rgbf<1.0, 0.2, 0.2, 1.0> // 虹を作る rainbow { angle 42.5 width 5 distance 1.0e7 direction <-0.2, -0.2, 1> jitter 0.01 colour_map { [0.000 colour r_violet1] [0.100 colour r_violet2] [0.214 colour r_indigo] [0.328 colour r_blue] [0.442 colour r_cyan] [0.556 colour r_green] [0.670 colour r_yellow] [0.784 colour r_orange] [0.900 colour r_red1] } } jitterキーワードを使用して不規則性がカラーバンドに加えられる。 図　カラフルな虹。 我々のサンプルの中の虹は、あまりに明るい。あなたは、このような虹をこれまで実際には見たことがないだろう。あなたは、カラーマップの中のRGB値を減少させることによって虹のカラーを減少させることができる。 4.10.5.2 虹の半透明性を増やす 我々の得た結果は今までのところあまりに明るく見える。虹の色を減らすことはそれを改善するけれども、それより虹の半透明性を増やすことの方が虹を通して背景が透けて見えるようになるのでよりリアルである。 我々が、霧でやったように、カラーマップの中で最小限の半透明性を指定するためにカラーの透過率チャネルを使用することができる。あなたが下記の例(rainbow2.pov)で見ることができるように、リアルな結果を得るために、我々は非常に大きい透過率値(transmit)を使用しなければならない。 rainbow { angle 42.5 width 5 distance 1.0e7 direction <-0.2, -0.2, 1> jitter 0.01 colour_map { [0.000 colour r_violet1 transmit 0.98] [0.100 colour r_violet2 transmit 0.96] [0.214 colour r_indigo transmit 0.94] [0.328 colour r_blue transmit 0.92] [0.442 colour r_cyan transmit 0.90] [0.556 colour r_green transmit 0.92] [0.670 colour r_yellow transmit 0.94] [0.784 colour r_orange transmit 0.96] [0.900 colour r_red1 transmit 0.98] } } 　柔らかに背景に混ざり合うように作成するために透過率値(transmit)を外側の虹のバンドで増やす。 図　よりリアリスティックな虹。 4.10.5.3 虹の弧を使う 現在、我々の虹は、たとえその多くが地上平面の下に隠されるとしても円形である。あなたは、arc_angleキーワードを使用することによって簡単に360度以下の角度で虹の弧をつくることができる。 あなたが例えばarc_angle 120を使用するならば、あなたは弧の端で急に消える虹の弧を得る。これは、良く見えない。これを避けるために、弧が、どこで背景になめらかに融合するかの領域をfalloff_angleキーワードで指定することができる。 虹のリファレンスセクション(「虹」を見なさい)の中で説明されるように、虹は -arc_angle/2 から arc_angle/2 まで広がる。混合は-arc_angle/2 から -falloff_angle/2 およびfalloff_angle/2 から arc_angle/2まで起こる。これが、falloff_angleがarc_angle以下でなければならない理由である。 以下の例で我々は、両側で45度の減少領域を持つ120度の弧を使用する(rainbow3.pov)。 rainbow { angle 42.5 width 5 arc_angle 120 falloff_angle 30 distance 1.0e7 direction <-0.2, -0.2, 1> jitter 0.01 colour_map { [0.000 colour r_violet1 transmit 0.98] [0.100 colour r_violet2 transmit 0.96] [0.214 colour r_indigo transmit 0.94] [0.328 colour r_blue transmit 0.92] [0.442 colour r_cyan transmit 0.90] [0.556 colour r_green transmit 0.92] [0.670 colour r_yellow transmit 0.94] [0.784 colour r_orange transmit 0.96] [0.900 colour r_red1 transmit 0.98] } } 弧の角度は、虹の上に向かう方向に対して測定され、それはupキーワードで指定することができる。デフォルトで、上に向かう方向は、y-軸である。 図　虹の弧。 4.10.6 アニメーション(Animation) 一連の静止画の(POV-Rayが出力するような)TGAファイルを取り込んでアニメーションに組み立てるたくさんのプログラムが利用可能である。そのようなプログラムはAVI、MPEG、FLI/FLC、あるいは(World Wide Webでの利用のための)動画化されたGIFファイルを作成することができる。したがって秘訣はどのようにフレーム(一コマ)を作成するかである。もちろんそれがPOV-Rayがどうしてできたかである。初期のバージョンのアニメーションシリーズの製作は、すべてを手作業でしなければならない楽しい物ではなかった。clock値を設定し、個々のフレームを手作業でユニークな名前を作るようにしなければならなかった。バッチファイルか同様のスクリプト手段を用いてある程度自動的に扱うことができたが、まだ、それらの設定をすべて手作業でしなければならなかった。そしてそれは大変な仕事であった(失敗には言及しないが... 別々の名前を設定することを忘れて24時間後に戻ってきたら結局それぞれのフレームが上書きされているのを知ったというようなことを想像してくれ)。 今、ついに、POV-Ray 3ではより良い方法がある。もうばらばらのバッチスクリプトや配列するための外部のプログラムは必要ない。なぜならINIファイル(あるいはコマンドライン)への2、3の簡単な設定がPOV-Rayに自動的にアニメーションループの細目を扱わせるための内部のアニメーションシーケンスを始動させるからである。 実際に、そこにアニメーションサポートの半分がある:われわれがINIファイル(あるいはコマンドライン)に置くそれらの設定と、シーン記述言語に働かせるコードの修正である。もし、以前のバージョンのPOV-Rayですでにアニメーションの作業をしたことがあれば、たぶん以下の「INIファイルの設定」のセクションの先頭までスキップすることができる。そうでなければ、基礎から始めよう。内部アニメーションループを始動させる方法を得る前に、時間によるオブジェクトの運動を記述するためにどのように2つのキーワードが我々のコードを組み立てるかを2つの例で見てみよう。 4.10.6.1 Clock変数:そのすべての鍵(The Clock Variable: Key To It All) POV-Rayは(すべて小文字の)clockで識別される自動的に宣言される浮動小数点変数をサポートしている。これはイメージファイルの作成を自動化するための鍵である。コマンドライン操作で、clock変数は +kスイッチを用いて設定できる。例えばコマンドラインからの+k3.4はclockの値を3.4に設定する。同じことを、INIファイルから達成することができる Clock = 3.4 もしclockに何も設定せずに、アニメーションループが使われない場合も(少し後で述べるように)clock変数は存在し、デフォルトの値0.0に設定されるので、アニメーションの目的のためのいくつかのPOVコードをセットアップすることが可能であり、我々のプロジェクトのオブジェクト/世界の作成ステージの間、静止画としてレンダリングされる。 この利点を用いた最も簡単な例は、x-軸に沿って、一定の率で移動しているオブジェクトを持つものであろう。我々のオブジェクトの宣言に以下の文を入れ translate それから、次第に高い値をclockに割り当てるアニメーションループを持つ。それは素晴らしい。シーンのたった一つのオブジェクトあるいは外観が変化している。しかし、我々が同じシーンの中で同時に複数の変化を制御したいとき何が起こるか？ ここの秘密は標準化されたclock値を使うことである。それからあなたは、シーンの中の他の変数ををclockと比例するようにしなさい。すなわち、clockを設定する時に(それに着手している。我慢!)それを0.0から1.0まで走らせなさい、それからそれを他の変数の乗数として用いなさい。その方法で、別の値がわれわれの欲しい物になり、clockはすべてのアプリケーションに対して同じ0から1の値のままである。(相対的に)簡単な例を見てみよう #include "colors.inc" camera { location <0, 3, -6> look_at <0, 0, 0> } light_source { <20, 20, -20> color White } plane { y, 0 pigment { checker color White color Black } } sphere { <0, 0, 0> , 1 pigment { gradient x color_map { [0.0 Blue ] [0.5 Blue ] [0.5 White ] [1.0 White ] } scale .25 } rotate <0, 0, -clock*360> translate <-pi, 1, 0> translate <2*pi*clock, 0, 0> } 一連のフレームはclockが0.0から1.0まで徐々に進むのとともに動作する物と仮定すると、上のコードは左から右にスクリーンを横切って転がる縞のボールを作成する。ここに2つの目標がある: 1.ボールを点Aから点Bに平行移動する、そして 2.ボールを直線移動に対する正確に正しい比率で回転する。最終的な位置まで--滑るのではなく--回転することを意味する。 ２番目の目標について最初に述べると、われわれは原点の球から始める。なぜならば他のどこの場所でも回転は、回転でなく原点のまわりに軌道を描いて回るようになるからである。アニメーションの進行により、ボールは一回の完全な360度回転をするだろう。したがって、われわれは式 360*clockを各フレームの回転を決めるために用いる。clockが0から1まで進むので、球の回転は0度から360までなされる。 そして我々は、球をその初めの出発する点に置くために最初の平行移動(translation)を用いた。思い出そう、そこで単に宣言することはできなかった。そうしないと原点まわりの軌道で回ってしまう。そこでもう一つの目標(平行移動)に合わせる前に、球を最初にあった場所に戻して置いて埋め合わせをしなければならない。その後、再び球をclockに相対的な距離で平行移動し、開始点に相対的な移動を引き起こす。われわれは式 2*pi* r*clock(球の最も大きい円周×現在のclockの値)を選んだので、それが完全に360度回転したのと同じ時、球の円周に等しい距離を移動して現れる。このように、球の回転をその平行移動に同期させ、平面に沿って滑らかに転がるように見えるようにした。 より手際良く、時間による複数の状況の変化のコーディネートを我々に与える他に、数学的に話すと、正規化されたclock値の使用の他の良い理由は、10フレームの動画GIFか300フレームのAVIかは問題にならなくなることである。clockの値はフレーム番号に比例するので、POVのコードはフレームシーケンスがどのくらい長いかにかかわらず動作する。われれの転がるボールは、アニメーションがどのくらいの数のフレームで終了するかに関わらず正確に同じ量だけ移動する。 4.10.6.2 clock依存変数とマルチ・ステージ・アニメーション Ok、アニメーションの最初の半分でボールを左から右に転がし、それから方向を135度変えて右から左に転がし、そしてシーンの後ろの方へやりたいとしたらどうだろう。POVの新しい条件付きレンダリング命令を使い、半分の地点にいつたどり着いたかを決めるためにclock値をテストし、それからそれぞれのclockに依存したシーケンスをレンダリングする必要が生ずる。しかし上のような我々の目標は、(正規化された)0から1の範囲の変数を持つ各ステージでそれを働かせることである。なぜならこれはアニメーションの間複数の状況をコントロールしなければならない時、その数学をより完全に働かせるからである。そこで、同じカメラ、光源および平面を保ち、clockを0から2まで走らせよう! 今、一つの球の宣言を以下で置き換えよう... #if ( clock <= 1 ) sphere { <0, 0, 0> , 1 pigment { gradient x color_map { [0.0 Blue ] [0.5 Blue ] [0.5 White ] [1.0 White ] } scale .25 } rotate <0, 0, -clock*360> translate <-pi, 1, 0> translate <2*pi*clock, 0, 0> } #else // (もし clock が > 1なら、第二の段階にある) // まだ、0-1の値で作業をしたい #declare ElseClock = clock - 1 sphere { <0, 0, 0> , 1 pigment { gradient x color_map { [0.0 Blue ] [0.5 Blue ] [0.5 White ] [1.0 White ] } scale .25 } rotate <0, 0, ElseClock*360> translate <-2*pi*ElseClock, 0, 0> rotate <0, 45, 0> translate } #end 我々が真相にスポットライトをあてると、これによってボールがその方向を変えているとき、非現実的なスナップターンをするようになるだろう。我々のためのボーナスポイントである−我々は生まれながらのアニメーターである。しかしながら、例を簡単にするため、今はそれを無視しよう。それを現実的な世界に修正するのは十分簡単であるが、今あるコードがどのように働くかを見てみよう。 われわれが変えて行ったすべては、clockが0から2まで変化し、代わりに正規化された値で作業したかったと仮定したことである。したがって、clockが1.0を越えて進んだとき、POVは行程の第二段階を開始すると仮定し、そして我々はオリジナルの組み込みclockに相対的にした新しい変数Elseclockを宣言した。そのような方法で、clockは1から2に進むが、Elseclockは0から1まで進む。したがって、たった一つのclockしかなくても、われわれが宣言したいと思うだけの(そしてそのためのメモリーがあれば)たくさんの追加の変数が存在できる。したがって、きわめて複雑なシーンでも、一つのclock変数が、すべての他の動きを編曲する一般の調整係数を作れる。 4.10.6.3 Phase(位相)キーワード アニメーションの目的のために知っておくべきもう一つのキーワードがある:phase(位相)キーワードである。phaseキーワードは多くのテクスチャエレメント、特にカラー、ピグメント、法線あるいはテクスチャマップを持つことができるもので使うことができる。それらのマップがとる形を思い出そう。例えば: color_map { [0.00 White ] [0.25 Blue ] [0.76 Green ] [1.00 Red ] } それぞれのカギ括弧の組の内側の左の浮動小数点数値はPOV-Rayがテクスチャ付けされるオブジェクトの様々な領域にカラーの値をマップするのを助ける。マップが、見事に0.0〜1.0まで動くのに気がつく？ Phaseはカラー値をキーワードphaseに続く浮動小数点数値でマップに沿ってシフトされるようにする。今、もし我々がともかくすでに正規化されたclock値を用いているとすると、変数clockをphaseに関連づけられた浮動小数点数値にすることができ、パターンはアニメーションのコース上でなめらかにシフトする。gradient法線パターンを用いている一般の例を見てみよう #include "colors.inc" #include "textures.inc" #background { rgb<0.8, 0.8, 0.8> } camera { location <1.5, 1, -30> look_at <0, 1, 0> angle 10 } light_source { <-100, 20, -100> color White } // 旗 polygon { 5, <0, 0>, <0, 1>, <1, 1>, <1, 0>, <0, 0> pigment { Blue } normal { gradient x phase clock scale <0.2, 1, 1> sine_wave } scale <3, 2, 1> translate <-1.5, 0, 0> } // ポール(旗竿) cylinder { <-1.5, -4, 0>, <-1.5, 2.25, 0>, 0.05 texture { Silver_Metal } } // ポールキャップ sphere { <-1.5, 2.25, 0>, 0.1 texture { Silver_Metal } } 今、ここで我々は、gradient法線パターンを持つ簡単な青い旗を作成した。それがまるでそよ風の中でひらひら動いているように、旗が前後にうねるように見えるように、我々はgradientにsine-wave(正弦波)タイプの波を使うのを強制した。しかし、ここでの実際のマジックは、そのphaseキーワードである。それはclock変数を浮動小数点数値としてとるように設定され、clockがゆっくり1.0に向かって増やされるのにつれ、それは旗の波の山と谷をx-軸に沿ってシフトする。効果的に、我々がこのコードによって作成されたフレームをアニメーションにするとき、それは旗が風の中で実際に波が立っているように見えるだろう。 これは、clockに依存するphaseのシフトがどのように面白いアニメーション効果を作成することができるかのほんの一つの簡単な例である。いろいろなテクスチャパターンでphaseを試すと、実際にオブジェクトを動かすことなく単にphaseだけで簡単に作成できるアニメーション効果の範囲に驚かされる。 4.10.6.4 Jitter や Crandを使用するな 失敗を防ぐ最後の一つの基本的な情報。ジッタ(jitter)はアンチエイリアシングの要素であるから、われわれは簡単にこれについてINIファイル設定セクションで触れることができたが、しかし、エリア光とPOV-Rayの新しい大気の効果で使われるアンチエイリアシングの形式もあるので、今が良いときである。 ジッタは、別の方法では強いアンチエイリアシングでさえも、すっかり消えないかも知れない小さいエイリアシング誤差を拡散するために設計された非常に少ない量のランダムな光線の動揺である。間違っているピクセルの配置をランダム化することにより、誤差は人間の目には目立ちにくくなる。なぜなら、当然、目と心はランダムなゆがみよりも規則的なパターンを見ることに傾けられるからである。 静止した絵のためには素晴らしく働くこの概念は、アニメーションの中の悪夢になる可能性がある。なぜなら、それが事実上ランダムであるので、レンダリングするそれぞれのフレームで異なる。そして、これは最終結果をディザし、(FLCのような)256色アニメーションに落とすときにより厳しい物になる。結果はシーンの至る所で跳ねるピクセルになり、特にエイリアシングが通常問題となる場所に集中する(例えば、無限の平面が遠景に消える場所) この理由のために、アニメーションのシーンを準備をしているとき、常に、我々はエリア光とアンチエイリアスオプションでジッタをoffにセットしなければならない。(相対的に)小さいジッタの使用による余分な測定品質は、その結果の飛び跳ねる海で相殺される。この全般的な規則は、crandのような本当にランダムなテクスチャ要素にも適用される。 4.10.6.5 INI ファイルの設定 OK、そう、アニメーションのためのファイルをどのようにコード化するかをしっかり把握する。われわれは、clock変数、ユーザが宣言したclockに相対的な変数、およびphaseキーワードについて知っている。シーンをレンダリングするときとすべて設定してアニメーションを構築するときにjitterやcrandをしないことを知っている。よろしい、それに備えていよう。 我々が知る必要のある最初のコンセプトはINIファイル設定、Initial_FrameとFinal_Frameである。これらは全く手を掛けない方法で、特定の数のフレームをそれぞれがユニークなフレーム番号を持つようにレンダリングできるようにするとても簡単な設定である。もちろん、目もくらむようにシンプルなので、説明の必要は僅かであるが、とにかく例がある。好みのINIファイル設定に以下の行を加えるだけである Initial_Frame = 1 Final_Frame = 20 そして、20のユニークなフレームを生成する自動化されたループを初期化する。設定それ自身で、自動的にフレーム番号を設定した出力ファイル名の末尾に付ける。したがって、そのことを考えなくても、個々のフレームにユニークな番号が付けられる。第二に、デフォルトで、clock値はフレームの数と比例して増加し、0から1まで巡回させる。これは非常に便利である、5フレームの動画GIFか300フレームのMPEGシーケンスを作成しているかどうかに関係なく、正確に同じスタートから正確に同じ終わりまでスムーズに巡回するclock値を得られる。 次に、clockについてである。転がるボールのコードの我々の例では、ときどきデフォルト0.0から1.0まで以外の値での範囲で巡回するclockを欲しくなることが分かった。その場合、そのための設定もある。そのフォーマットもまたシンプルである。我々の例のように、0.0から2.0までclockを走らすために、INIファイルに以下の行を加えるだけでよい Initial_Clock = 0.0 Final_Clock = 2.0 今、100フレームのシーケンスを開発しているとしよう。そして、我々はフレームのどこか、51〜75としよう、に視覚的な小さな欠陥を発見した。我々はコードに戻り、それを修正したと思う。最初からすべてのフレームを再実行する代わりに、それらの25フレームだけをレンダリングしたいと思うだろう。何を変更すればよいのか? もし、Initial_Frame = 51と Final_Frame = 75 だといえば、それは間違いである。たとえこれで15から75までに名付けられたファイルが再レンダリングされととしても、それらはわれわれのシーケンスに正しくフィットしないだろう。なぜならclockがその初期値でフレーム51から開始され、フレーム75で終わる最終値まで巡回する。Initial_Frame と Final_Frameを変更すべき時は、既存の材料に追加される本質的に新しいシーケンスを行っている時だけである。 もし元のアニメーションのちょうど51から75までを見たいのなら、新しいINI設定 Subset_Start_Frame = 51 Subset_End_Frame = 75 を以前からの設定に加えることが必要である。clockはまだその値をフレーム1から100まで巡回するが、51番目から75番目までのフレームのシーケンスの部分だけがレンダリングされているだろう。 これは、我々にアニメーションをどのように使うかのアイディアを与える。けれども、入門のチュートリアルではすべての角度からカバーすることはできない。例えば、今見た最後の2つの設定、サブセットアニメーショは、0.5から0.75までのような分数値をとることができる。したがって、実際のフレームの数は、アニメーションのどの部分がレンダリングされているかを変えないだろう。また、テレビのようなインターレース再生での表示のために準備されたアニメーションに便利な、効率的な偶数-奇数フィールドレンダリングのサポートもある(完全な詳細のためにリファレンスセクションを見なさい)。 今、アニメーションオプションの完璧なホストを完全にサポートしているPOV-Ray 3で、全部の第四次元が、レイトレーシング体験に追加される。われわれがFLIC、AVI、MPEGあるいはウェブサイトのための簡単な動画GIFのどれを作っているかに関係なく、アニメーションのサポートはたくさんの退屈を処理から取り除く。phaseとclockが、マスターすることがより難しいオブジェクト(ヒント:たとえばジュリアフラクタル)と同様に、多数のテクスチャ要素を調査するために使えるということを忘れないで下さい。それで、たとえ完全に静止シーンを作ることに満足しているとしても、レパートリーにアニメーションを加えることはPOV-Rayがどんな能力があるのかの我々の理解を大いに改良することができる。冒険が待っている! 5 POV-Rayリファレンス リファレンスセクションは、すべてのコマンドラインオプションとINIファイルスイッチ、POV-Rayの一部であるシーン記述言語とすべての他のフィーチャーを記述する。これは事項を参照するために使われることを想定している。シーンを書く方法やPOV-Rayを使う方法の詳細な説明は含まない。ただすべての機能、それらの文法、応用、限度、欠点などを説明する。 6 POV-Ray のオプション POV-Rayは元々グラフィックインタフェースやダイアログボックス、プルダウンメニューのないオペレーティングシステムのためのコマンドラインプログラムとして作られた。POV-Rayのほとんどの版は、何をするかを指示するためにまだコマンドラインスイッチを使う。このドキュメンテーションは、あなたがコマンドライン版を使っていると仮定する。あなたがマッキントッシュ、MS-Windowsや他のGUI版を使っているならば、同じことをするダイアログボックスかメニューがあるだろう。各システムのための固有のコマンドを記述しているシステム特定のドキュメンテーションがある。 6.1 POV-Rayのオプションの設定 POV-Rayオプションをセットする2つの別個の手段がある：コマンドラインスイッチとINIファイルキーワードである。両者は、以下のセクションの中で詳細に説明される。 6.1.1 コマンドラインスイッチ コマンドラインスイッチは、一つ以上の英字とおそらく数字で表した値がそれに続く＋（プラス）あるいは−（マイナス）符号から成る。以下はスイッチをもつ代表的なコマンドラインである。 POVRAY +Isimple.pov +V +W80 +H60 povrayはプログラムの名前である。そして、いくつかのスイッチがそれに続く。各スイッチは、正あるいは負の符号から始まる。ファイル名をもつ+Iスイッチは、それが入力としてどんなシーンファイルを使わなければならないかをPOV-Rayに教える。+Vは、プログラムが動作している最中に、その状態をテキストスクリーンに出力するように指示する。+Wと+Hスイッチは、イメージの幅と高さをピクセル数でセットする。このイメージは、60ピクセルの高さで80ピクセルの幅である。 機能を切り換えるスイッチにおいて、プラスはそれをonにする、そして、マイナスはそれをoffにする。たとえば+Pは終了時にキーが押されるまで休止するオプションをオンにし、-Pはそれをオフにする。他のスイッチは、値を指定するために使われて、機能を切り換えない。プラス・マイナスいずれも、実例の中で使われるかもしれない。例えば、+W 320は、幅を320ピクセルにセットする。また、あなたは-W 320を使うことができ、同じ結果を得ることができる。 スイッチは、大文字、小文字どちらで指定してもよい。それらは左から右へ読まれるが一般にはどの順番で指定しても良い。あなたが2度以上スイッチを指定した場合、それ以前の値は、一般に最後の定義で上書きされる。例外は、ライブラリパスをセットするための+Lスイッチである。最高10のユニークなパスを指定することができる。 ほとんどすべての＋・-スイッチはINIファイルで使われるそれと等価なオプションがあり、それは次のセクションで述べる。各スイッチの詳細な記述は、オプションリファレンスセクションで与えられる。 6.1.2 INI ファイルを使う コマンドライン上では，数個のオプションより多くのオプションを設定をするのが難しいので、あなたは複数のオプションを一つ以上のテキストファイルに入れることができる。これらの初期化ファイルあるいはINIファイルは、それらのデフォルト拡張子として.iniを持つ。POV-Rayの以前の版は、それらをデフォルトファイルあるいはDEFファイルと呼んだ。あなたは、まだこの版のPOV-Rayで既存のDEFファイルを使ってもよい。 あなたが使うオプションの大多数は、INIファイルに保管されるだろう。コマンドラインスイッチはあなたが開発中のシーンのテストレンダリングを実行する時のように頻繁にon/offを行うオプションに対してお勧めである。ファイルpovray.iniは、もしそれがあれば自動的に読まれる。あなたは、単にコマンドライン上でファイル名をタイプすることによって、コマンドライン上で追加のINIファイルを指定することもできる。 例： POVRAY MYOPTS.INI 拡張子が与えられなければ、.iniが仮定される。POV-Rayは、それがプラスあるいはマイナスの後でないのでこれがスイッチでないのを知っている。実際、新しいユーザにおけるありふれたエラーは、彼らが+Iスイッチを入力ファイル名の前に置くのを忘れるということである。スイッチなしでは、POV-Rayはシーンファイルsimple.povがINIファイルだと思う。コマンドラインスイッチにプラスもマイナスも先行しなければ、それはINIファイル名であると仮定されるということを忘れないで下さい！。 あなたは、コマンドライン上でスイッチとともに複数のINIファイルを指定することもできる。 たとえば： POVRAY MYOPTS +V OTHER これは、myopts.iniからオプションを読み込み、そして+Vスイッチ設定する、そしてother.iniからオプションを読み込む。 INIファイルは、全くのアスキーテキストファイルであり、以下の形式のオプションをもつ... Option_keyword=VALUE ; セミコロンの後ろのテキストはコメントである 例えば、スイッチ+I simple.povのINI相当語句がある... Input_File_Name=simple.pov オプションは先頭から末尾までファイルの中から読まれる、しかし、一般にはどんな順序で指定してもよい。あなたが二度以上オプションを指定した場合、一般にそれ以前の値は、最後の定義で上書きされる。例外は、Library_Path =パスオプションである。最高10のユニークなパスを指定できる。 ほとんどすべてのINI-スタイルオプションは、同意義の+ / -スイッチを持つ。オプションリファレンスセクションには、すべてのPOV-Rayオプションの詳細な記述がある。そこにはINI-スタイル設定、そして、+ / -スイッチの両方含む。 INIキーワードは、大文字と小文字の区別ができない。テキストの１行につき一つのINIオプションだけが許される。それらがあなたにとってより容易であるならば、あなたはスイッチをあなたのINIファイルに含めてもよい。あなたは１行につき複数のスイッチを指定することもできる。しかし、あなたは同じ行でスイッチとINIオプションを混在させてはならない。あなたは単にファイル名をその後ろに等号なしで行に置くだけでINIファイルをネストせることができる。ネスティングは、深さ10のレベルまで行える。 例えば: ; これは、サンプルINIファイルである。この行全体は、コメントである。 ; ブランク行は、許される。 Input_File_Name=simple.pov ;これは入力ファイル名をセットする +W80 +H60 ; 伝統的な +/- スイッチも許される MOREOPT ; MOREOPT.INI を読み込み次の行を続けなさい +V ; 別のスイッチ ; これですべてである! INIファイルは、ラベルを付けたセクションを持つことができる。したがって複数のオプション群を一つのファイルに保存することができる。各セクションは、[ ]ブラケット内のラベルから始まる。例えば： ; RES.INI ; このサンプルINIファイルは解像度をセットするのに使われる。 +W120 +H100 ; このセクションにはラベルがない。 ; "RES"でそれを選択しなさい [Low] +W80 +H60 ; このセクションにはラベルがある。 ; "RES[Low]"でそれを選択しなさい [Med] +W320 +H200 ; このセクションにはラベルがある。 ; "RES[Med]"でそれを選択しなさい [High] +W640 +H480 ; ラベルは大文字小文字を区別しない ; "RES[high]" はうまく動作する [Really High] +W800 +H600 ; ラベルは空白を含んでも良い あなたがINIファイルを指定するとき、あなたはブラケットの中のセクションラベルをそれに続けなければならない。 たとえば... POVRAY RES[Med] +Imyfile.pov POV-Rayはres.iniを読んで、ラベルMedを見つけるまで、すべてのオプションをスキップする。そのラベルの後のオプションを別のラベルが見つかるまで処理し、その後はスキップする。ラベルがコマンドライン上で指定されなければ、ファイルの最上位のラベルのない領域が読まれる。ラベルが指定されると、ラベルのない領域は、無視される。 6.1.3 POVINI 環境変数を使う 環境変数POVINIは、デフォルトINIファイルの位置と名前を指定するために使われる。そしてそれは、POV-Rayが実行される時に毎回読み込まれる。POVINIが指定されていなければ、デフォルトINIファイルは、使われているプラットホームに従って読まれる。指定されたファイルが存在しなければ警告メッセージが出力される。 MS-DOSの下で環境変数をセットするために、あなたは以下の行をautoexec.batファイルに入れてもよい.. set POVINI=c:\povray3\default.ini ほとんどのオペレーティングシステム上でオプションを読む順序は、次のようである： 1. POVINI環境変数かプラットホーム特定のINIファイルによって指定されたデフォルトINIファイルからオプションを読む。 2. コマンドライン（これは、指定されたINI/DEFファイルを読むことを含む）からスイッチを読む。 以前のPOV-Ray版でサポートしていた環境変数POVRAYOPTは、もはや利用できない。 6.2 オプションリファレンス 前のセクションで説明したように、オプションはスイッチかINI-スタイルオプションによって指定することができる。ほとんどすべてのINI-スタイルオプションが、同等の＋/-スイッチを持ち、ほとんどのスイッチが、同等のINI-スタイルオプションを持つ。以下のセクションは、各POV-Rayオプションの詳細な説明を与える。それはINI-スタイル設定、そして、＋/−スイッチの両方を含む。 使われた表記法と用語は、以下の表の中で記述される。 Keyword=bool boolがtrue、yes、onあるいは1の場合、Keywordをonに切り替え、 それ以外の値の場合offに切り替える。 Keyword=true true、yes、onおよび1が指定された場合このオプションが実行さ れる。 Keyword=false false, no, off あるいは 0が指定された場合このオプションが実行さ れる。 Keyword=file 有効なファイル名。 注:いくつかのオプションはファイル名として上 記のtrueあるいはfalseの値の使用を禁止する。それらは後のセクシ ョンで記す。 n +W320 に使われているような任意の整数 n.n Clock=3.45 に使われているような任意の浮動小数点数 0.n 任意の1.0 より小さい浮動小数点数。先導する0は無くても良い s 任意の文字列 xあるいは y 任意の１文字 path ディレクトリ名、ドライブはオプション、最後にパスの区切り文字は付 けない。(オペレーティングシステムにより"\"あるいは"/") 特に注意がなければ、あなたは、スイッチの前のプラスおよびマイナス符号が同じ結果を生じるものとしてもよい。 6.2.1 アニメーション・オプション POV-Ray 3.0 は内部アニメーションループの追加、出力ファイル名の自動ナンバリング、および個々のフレームをアニメーションに組み立てる外部ユーティリティのためのオペレーティングシステムへのシェルアウトの追加によりアニメーション能力を大いに改善した。内部のアニメーションループは、単純だが柔軟である。内部のループなしでアニメーションをつくるために、あなたがPOV-Ray 2でそうしたように、外部のプログラムやバッチファイルをまだ使うことができる。 6.2.1.1 外部アニメーションループ Clock=n.n "clock"float(浮動小数点数)識別子を n.nにセットする。 +Kn.n Clock=n.nと同じ Clock =n.nオプションあるいは+K n.nスイッチは、基本的なアニメーションのためにプログラムに一つのfloat値を渡すために使うことができる。値は、float識別子clockに保管される。オブジェクトにrotate <0,clock,0>を付けておけば、異なるフレームに対して異なる量によって[+]K 10.0, +K 20.0...などを連続したレンダリングにセットすることによって、あなたはオブジェクトを回転させることができる。異なるClock値と異なるOutput_File_Nameで各フレームのために繰り返しPOV-Rayを呼び出すことは、ユーザ次第である。 6.2.1.2 内部アニメーションループ Initial_Frame=n 最初のフレーム番号をnにセットする Final_Frame=n 最終フレーム番号をセットする Initial_Clock=n.n clockの初期値をセット Final_Clock=n.n clockの最終値をセット +KFIn Initial_Frame=nと同じ +KFFn Final_Frame=nと同じ +KIn.n Initial_Clock=n.nと同じ +KFn.n Final_Clock=n.nと同じ POV-Ray 3.0にとって新しい内部アニメーションループは、異なる設定でPOV-Rayを複数回呼び出すための複雑なバッチファイルのセットを作成する作業をユーザから取り除く。 多数のオプションは脅迫的に見えるが、デフォルト値の賢いセットは、あなたがフレームの数を指定するためにFinal_Frame =nか+KFF nオプションを指定する必要があるだけだということを意味する。すべての他の値は、それらのデフォルトのままでもよい。 -1以外のFinal_Frameの設定は、POV-Rayの内部のアニメーションループの引き金となる。例えば、Final_Frame =10あるいは+KFF 10によってPOV-Rayがあなたのシーンを10回レンダリングするようになる。あなたがOutput_File_Name = file.tgaを指定すると、各フレームの出力はfile01.tga、file02.tga、file03.tgaなどとなる。ファイル名の中のゼロ詰めされた桁の数は、最終的なフレーム番号に依存する。例えば、+KFF 100は、file001.tgaからfile100.tgaまでを順に生成する。フレーム番号は、ファイル名を侵食する可能性がある。8つのキャラクタ限度をもつMS-DOS上ではmyscene.povはmysce001.tgaからmysce100.tgaまでレンダリングされる。 多分、デフォルトのInitial_Frame =1は、変更する必要がないだろう。あなたがバラバラになっている長いアニメーションシーケンスを集めて組み立てる場合のみ変更することがあるだろう。一つのシーンは、フレーム1〜50、次は51〜100を実行するかもしれない。Initial_Frame =nと+KFI nオプションが、この目的のためにある。 あなたが1〜100のアニメーションの中の30から40までのようなフレームのサブセットをレンダリングしたいのならば、あなたは、Frame_InitialやFrame_Finalを変えるべきではないことに注意しなさい。その代わりに、あなたはセクション「アニメーションフレームのサブセット」の中で記述されたサブセットコマンドを使うべきである。 いくつかのアニメーションパッケージと違って、POV-Rayのアニメーションとして制作されたシーンの中の動作は、整数フレーム番号に依存しない。むしろあなたは、float識別子clockに基づいてあなたのシーンを設計するべきである。デフォルトで、clock値は、初めのフレームでは0.0で最終的なフレームでは1.0である。すべての他のフレームは、これらの値の間に差し込まれる。例えば、あなたのオブジェクトをアニメーションのコースの上で、一回のフルターン回転をさせる場合、あなたはrotate 360*clock*yを指定することができる。それで、clockが0.0から1.0まで進むにつれ、オブジェクトはy-軸について0〜360度回転する。 このシステムの主要な利点は、あなたが10か100のフレームあるいは、500か329フレームのアニメーションをレンダリングしても、なお，あなたは一回の360度フル回転を得るということである。数フレームのテストレンダリングが、多くのフレームの最終レンダリングと同様に正確に動作する。 要するに、あなたは連続するfloat値のパラメータ（clock）上で運動を定義する、そして、あなたはいくらかの固定された間隔（フレーム）で離散的なサンプルをとる。あなたが現実のシーンを映画かビデオテープに記録する場合も、それは同じ方法で動作する。オブジェクトの実際の運動は、時間だけに依存する。あなたのカメラのフレームレートには依存しない。 多くのユーザは、デフォルトで0.0〜1.0以外の範囲のclock値を期待するPOV-Ray 2のために、すでにシーンをつくった。この理由のために、我々はInitial_Clock =n.nか+KI n.n、そして、Final_Clock =n.n、あるいは、+KF n.nオプションを与える。例えば、25.0から75.0までclockを走らせるために、あなたはInitial_Clock =25.0とFinal_Clock =75.0を指定する。それで、clockは初めのフレームのために25.0に最終的なフレームのために75.0にセットされる。フレームの間のclock値は、25.0から75.0まで比例して挿入される。 clock値よりはむしろフレーム番号を使うことに慣れているユーザは、10フレームのアニメーションのためにInitial_Clock =1.0、そして、Final_Clock =10.0とFrame_Final =10を指定することができる。 新しいシーンのために、我々はあなたがInitial_ClockとFinal_Clockをそれらのデフォルトの0.0〜1.0の値から変えないことを勧める。あなたclock値をデフォルトの0.0から1.0までと異なる範囲で変化してほしいのならば、あなたのシーンファイルの内部で以下のようにそれを扱うことを勧める。 #declare Start = 25.0 #declare End = 75.0 #declare My_Clock = Start+(End-Start)*clock それでシーン記述の中でMy_Clockを使いなさい。これは、your.povファイルの中で臨界の値25.0と75.0を保持する。 アニメーションループの内の作業に関するより多くの詳細がセクション「オペレーティングシステムへのシェルアウト」の中のシェルアウト・オペレーティングシステムコマンドに関するセクションにある点に注意しなさい。 6.2.1.3 アニメーション・フレームのサブセット Subset_Start_Frame=n サブセットの開始フレームをnにセット Subset_Start_Frame=0.n サブセットの開始フレームnパーセントにセット Subset_End_Frame=n サブセットの終了フレームをnにセット Subset_End_Frame=0.n サブセットの終了フレームをnパーセントにセット +SFn or +SF0.n Subset_Start_Frameと同じ +EFn or +EF0.n Subset_End_Frameと同じ 長いアニメーションをつくっているとき、それがどんな風に見えるか見るために少しのアニメーションだけを表現することが手ごろであろう。あなたが100のフレームを持ち、そのフレーム30から40までを通して表現したいと仮定しなさい。あなたがInitial_Frame =30とFinal_Frame =40をセットすれば、それがそうするべきであるように、clockはフレーム30から40までを通して、0.30から0.40ではなくむしろ0.0〜1.0まで変化する。したがって、あなたはInitial_Frame =1とFinal_Frame =100を残すべきで、シーンの部分を選択的に表現するためにSubset_Start_Frame =30とSubset_End_Frame =40を使うべきである。POV-Rayは、それで正しくclock値を計算するだろう。 通常、あなたは実際の整数フレーム番号を用いてサブセットを指定するだろう。しかし、サブセットコマンドの代替の形式は範囲0.0<=n.nnn <=1.0のfloat値をとる。これは全部のアニメーションの一部分と解釈される。例えば、Subset_Start_Frame =0.333とSubset_End_Frame =0.667は、フレームの数に関係なくシーケンスの中間の1/3を表現する。 6.2.1.4 サイクリック(周期的)アニメーション Cyclic_Animation=bool サイクリック・アニメーションのon/offを切り替える +KC サイクリック・アニメーションをonにする -KC サイクリック・アニメーションをoffにする 多くのコンピュータ・アニメーション・シーケンスは、連続したループで動作するように設計される。あなたがあなたのアニメーションのコースで正確に360度を回転するオブジェクトを持つと仮定しよう。そして、あなたはそのためにrotate 360*clock*yを行った。最初と最後のフレームは、同一である。再生時に短い一つのフレーム痙攣(jerkiness)がある。この問題を排除するために、あなたは最後のフレームが最初のものと同じにならないようにclockを調節する必要がある。例えば、10フレームの周期的なアニメーションは、clock 0.0〜1.0を使うべきではない。0.1ずつ増加して0.0から0.9まで行うべきである。しかし、あなたがフレームを20に変えるならば、それは0.0から0.95まで0.05の増加で走らせるべきである。あなたがFinal_Frameを変える度に、最終的なclock値を変えなければならないので、これは事を複雑にする。Cyclic_Animation =onをセットするか、+KCを使うと、POV-Rayは自動的に、全フレーム数に関係なく周期的なアニメーションのために最終的なclock値を調節する。この設定のデフォルト値はoffである。 6.2.1.5 フィールド・レンダリング Field_Render=bool フィールド・レンダリングのon/offを切り替える Odd_Field=bool 奇数フィールドフラグをセットする +UF フィールド・レンダリングをonにする -UF フィールド・レンダリングをoffにする +UO 奇数フィールドフラグをonにセット -UO 奇数フィールドフラグをoffにセット アニメーションがテレビのための出力であるとき、時々、フィールド・レンダリング(field rendering)がアニメーションのために使われる。テレビは、各垂直リフレッシュでかわるがわるの走査線を表示するだけである。各フレームが表示されているとき、フィールドはより高解像度の画像の印象を与えるためにインターレースされる。偶数番の走査線は、偶数フィールドを作って、最初に描かれる（すなわち走査線0、2、4、など） ― 奇数のフィールドが続く、奇数番号の走査線が作られた後に描かれる。アニメーションの中のオブジェクトが速く動いていると、一つのフィールドから次のフィールドで目立つぐらいそれらの位置が変わることがある。この結果、これらのケースではPOV-Rayに標準のフレームレートでフルフレームをレンダリングさせるよりも、実際のフレームレート(フレームレートの2倍)で交互のフィールドをレンダリングさせることが望ましい場合があるだろう。これは2倍のフレームレートで全体のアニメーションをレンダリングし、いずれのフレームも半分しか使用しないのに比べて膨大な時間を節約するだろう。 デフォルトでは、フィールドレンダリングは使われない。Field_Render =onにセットするか+UFを使うと、アニメーションの交互のフレームがアニメーションの偶数あるいは奇数フィールドだけになるようになる。デフォルトで、最初のフレームは偶数フィールドで奇数フィールドが続く。Odd_Field =onを指定するか+UOスイッチを使えば、POV-Rayのレンダリングを奇数フィールドを最初にすることができる。 6.2.2 出力オプション 6.2.2.1 一般の出力オプション 6.2.2.1.1 出力の高さと幅 Height=n スクリーンの高さをnにセット Width=n スクリーンの幅をnピクセルにセット +Hn Height=n ( n > 8の時)と同じ +Wn Width=nと同じ これらのスイッチはイメージの高さと幅をピクセル数でセットする。これはファイル出力のイメージサイズを指定する。プレビュー表示は(もしonなら）このサイズに適応するようにビデオモードを選択しようと試みるだろう。しかし、ディスプレイ設定がどうであれ結果として作成されるファイル出力には影響はない。 6.2.2.1.2 部分出力オプション Start_Column=n 最初のカラムをnにセット Start_Column=0.n 最初のカラムを幅のnパーセントにセット +SCn or +SC0.n Start_Columnと同じ Start_Row=n 最初の行をnピクセルにセット Start_Row=0.n 最初の行を高さのnパーセントにセット +SRn or +Sn Start_Row=nと同じ +SR0.n or +S0.n Start_Row=0.nと同じ End_Column=n 最後のカラムをnにセット End_Column=0.n 最後のカラムを幅のnパーセントにセット +ECn or +EC0.n End_Columnと同じ End_Row=n 最後の行をnピクセルにセット End_Row=0.n 最後の行を高さのnパーセントにセット +ERn or +En End_Row=nと同じ +ER0.n or +E0.n End_Row=0.nと同じ テストレンダリングをしているときに小さい、長方形の、全スクリーンのサブセクションを定義することができれば、あなたは、す速くイメージの１領域をチェックすることができるので便利である。Start_Row、End_Row、Start_Column および End_Columnオプションはレンダリングするサブセット領域の定義を可能にする。デフォルト値はイメージのフルサイズで左上の(1,1)から右下の(w,h)までである。ここでwとhはあなたがセットしたWidth =n と Height =n の値である。 もし、指定された値が1より大きければ行とカラムのピクセル数の絶対値と解釈される。もし、それが0.0と1.0の間の十進数ならばイメージの全幅あるいは高さのパーセントと解釈される。例えば: Start_Row =0.75 と Start_Column =0.75 は上から75%下がった行で左から75%のカラムからスタートする。つまり、指定された幅と高さに関係なく右下の25%のイメージがレンダリングされる。 スイッチ +SR, +ER, +SC および +EC は絶対値セッティングとパーセントセッティングの両方に対して、対応する INI-スタイル・セッティングと同様に働く。初期のバージョンのPOV-Rayでは開始および終了行だけが+S nおよび+E nで指定できた。そこでそれらはまだ+SRと+ERに加えてサポートされている。 6.2.2.1.3 割り込みオプション Test_Abort=bool ユーザーによる中断のテストのon/offの切り替え +X 中断テストをonにする -X 中断テストをoffにする Test_Abort_Count=n 中断のテストを毎nピクセル毎にセット +Xn 毎nピクセル毎の中断のテストをonにセット -Xn 中断テストをoffにする(将来は毎nピクセル毎のテスト) いくつかのオペレーティングシステムでは、あなたが一度レンダリングを開始したら終了するまでそのままにしておかなければならない。Test_Abort =on オプションあるいは +X スイッチは、POV-Rayにキーが押されたかどうかのキーボードテストをさせるようにする。あなたがキーを押した場合、制御されたユーザー中断(アボート)を発生させる。ファイルはフラッシュされ閉じられる。しかし、最後にピクセルが満たされた行までのデータのみが保存される。 POV-Rayはエラーコード2で終了する (通常、POV-Rayは実行が正常終了すれば0を戻し、致命的エラーの場合は1を返す。)。 このオプションがonの場合、シーファイルの解析中は毎行ごと、レンダリング中は毎ピクセルごとにキーボードがポーリング(調査)される。キーボードのポーリングはレンダリング速度を低下させるので、Test_Abort_Count =n オプション、あるいは+X nスイッチは、nピクセルのレンダリングあるいはn行のシーン解析ごとだけにテストが働くようにする。 6.2.2.1.4 再開オプション Continue_Trace=bool 継続トレースをon/offにセット +C 継続トレースをonにセット -C 継続トレースをon/offにセット Create_Ini=file INI ファイルをfileに作成する Create_Ini=true file.iniを作成する。fileはシーン名。 Create_Ini=false 先にセットされたfile.iniの作成をoffにする。 +GIsss Create_Ini=sssと同じ レンダリングが進行中にあなたが中断した場合、あるいはあなたがEnd_Rowオプションを使って早めにレンダリングを終了した場合、あなたはContinue_Trace =on あるいは +Cオプションを使って、あなたが中断した場所から残りのレンダリングを後で継続することができる。このオプションは以前に作成された出力ファイルを読み込み、これまでにレンダリングされた部分イメージを表示し、それからレイトレーシングを続ける。このオプションはファイル出力がOutput_to_file =off か -Fで無効になっている時は使用できない。 Continue_Traceオプションは、Start_Rowオプションがファイルの先頭以外にセットされている場合働かない。これは使われているファイルフォーマットに依存する。 （訳注：BMP形式などファイルの先頭が、画像の最下行になっているファイル形式もある。） POV-Rayは指定された出力ファイルの中の作成済みのイメージを読み込んで、中断されたトレーシングをどこから再開すれば良いかを予想する。すべてのファイルフォーマットにはイメージサイズの情報が含まれているので、指定されたイメージサイズは無視される。いくつかのファイルフォーマット(すなわちTGAとPNG)ではまた、ファイルがどこからスタートするか(つまり、+SC n と +SR n オプション)、α出力+UA、ビットデプス(bit-depth:１ピクセルあたりの色数)+FN nなどの情報を保存している。これはそれらの設定を無視する。すべての他のオプションはオリジナルのレンダリングと同じにセットされるということを確信するかどうかはユーザー次第である。 Create_Ini オプションあるいは +GI スイッチはすべてのレンダリングオプションのINIファイルを作成する簡単な方法を与える。したがってあなたはファイルを同じオプションで再実行できる。あるいはすべて同じオプションでの再開を保証する。このオプションはそのレンダリングで使用された値にすべてのオプションをセットしたINIファイルを作成する。これはあなたが指定しなかったもののデフォルトの値も含む。例えばあなたが以下のオプションでPOV-Rayを実行した場合... POVRAY +Isimple.pov MYOPTS +GIrerun.ini MOREOPTS POV-Rayはこのシーンを生成するために使われたすべてのオプションを含むrerun.iniというファイルを作成する。全部のオプションが処理されるまでファイルは書かれない。このことは上の例では+GIスイッチがmyopts.ini と moreopts.iniの間で指定されたのにもかかわらずファイルはmyopts.ini と moreopts.ini両方からのオプションを含むことを意味する。あなたは今度はシーンを POVRAY RERUN で再実行することができる。あるいは中断されたトレースを POVRAY RERUN +C で再開することができる。 あなたがrerun.iniを引用時に他のスイッチを加えるならば、あなたがそれを使う度にファイルは書き直されるので、それらは以後の再実行で含められるだろう。 Create_Ini オプションはまた、どのようにシーンがレンダリングされたかを記録するのに便利である。あなたがwaycool.pov をCreate_Ini =onでレンダリングする場合、ファイル waycool.iniが作られる。 あなたのシーンとともにこのファイルを配布することができるので、他のユーザはあなたのイメージを正確に再生成させることができる。 6.2.2.2 ディスプレイ出力オプション 6.2.2.2.1 ディスプレイ・ハードウェアの設定 Display=bool グラフィック表示のon/offの切り替え +D グラフィック表示を on にする -D グラフィック表示を off にする Video_Mode=x ビデオモードを 'x'にセット; on/offには影響しない +Dx 表示を onにセット; モードを 'x'にセット -Dx 表示を offにセット; 将来はモード'x'を使う Palette=y ディスプレイ・パレットを 'y'にセット;on/offには影響しない +Dxy 表示を on; モードを 'x'; パレットを 'y'にセット -Dxy 表示を off; モード 'x'を使う, 将来はパレット 'y'を使う Display_Gamma=n.n ディスプレイのγ値を n.nにセット Display =on あるいは +D スイッチはレンダリング中のイメージのグラフィック表示をonに切り替える。グラフィックのないシステムでも、POV-Rayは80×24の文字によるアスキー・アート(ASCII-Art)版のイメージを表示できる。24-ビットのトゥルーカラーが利用できれば完全な表示になる。Display =offあるいは -D スイッチををセットするとグラフィックス表示はデフォルトのoffになる。 Video_Mode =x オプションはディスプレイモードあるいは選択されたハードウェアタイプをセットする。xは１文字の数字か英字でマシンに依存する(MS-DOS版でサポートされるモードの説明は"Display Types" を参照されたい)。一般に Video_Mode =0 はデフォルトあるいは自動検出の設定が使われる。スイッチが使われた場合、この文字はスイッチの直後になければならない。例えば+D0スイッチはグラフィック表示をデフォルトモードでonにする。 Palette =y オプションは使用するパレットをセットする。典型的には１文字のパラーメタ y は数字でいくつかの固定パレットの一つを選択し、文字Gはグレイスケール、 Hは15ビットあるいは16ビットのハイカラー、T は24ビット・トゥルーカラーである。スイッチを使う場合、その文字はスイッチの後ろの２番目の文字である。例えば、 +D0T スイッチはトゥルーカラーパレットのデフォルトモードでグラフィックディスプレイをonにする。 Display_Gamma =n.n 設定はPOV-Ray 3.0で新しくできた。コマンドラインスイッチでは利用できない。Display_Gammaの設定は異なるモニター、異なるビデオカードあるいは異なるオペレーティング・システムの下でイメージが(レイトレースされたものかどうかによらず)異なる輝度になるという問題を克服する。Display_Gammaはあなたのコンピュータのハードウェアに基づく設定であり、一度正確に設定したら変更すべきでない。 Display_GammaのINI設定は、作成されたPOVシーンとイメージがすべてのシステムで同じに見えるようにするために、新たなassumed_gammaグローバルセッティングに関連して働く。セクション"Assumed_Gamma"を参照されたい。そこではassumed_gammaグローバルセッティングとγ(gamma)について十分に説明している。 Display_Gammaはそれぞれのシステムで異なることがありうるが、あなたが正確にそれを知らないならば、Display_Gammaをセットするための２、３の全般的な規則を使うことができる。Display_GammaキーワードがINIファイルになければ、POV-Rayはディスプレイγに2.2を仮定する。これはほとんどのPCモニターが1.6 から 2.6の範囲の値を持つからである (最新のモデルでは低いγ値を持つようである）。MacOS はγ補正を行う能力をシステムソフトウェア内に持っている。(γコントロールパネルのユーザー設定に基づく)。γコントロールパネルがoffになっているか、利用できない場合、デフォルトのマッキントッシュシステムのγは1.8である。ハイエンドのPCグラフィックカードはハードウェアでγ補正ができ、正確なDisplay_Gamma設定が使え、大抵1.0である。γテスト用の画像は、ユーザがDisplay_Gammaを正確にセットするのを助けるために利用できる。 assumed_gammaのグローバルセッティングを持たないシーンファイルでは、POV-RayのDisplay_Gammaはプレビュー出力や出力ファイルフォーマットになんの影響も及ぼさない。しかし、Display_Gamma 値はPNGフォーマットの出力ファイルを作成するときには使われ、また、POV-Rayのサンプルファイルをレンダリングする際にも使われる(それらはassumed_gammaを持つから)。だから、本当の結果を保証するためには、あなたのシステムは正しくセットされていなければならない。 6.2.2.2.2 ディスプレイに関係する設定 Pause_When_Done=bool 終了時のポーズをon/offにセット +P 終了時のポーズをonにセット -P 終了時のポーズをoffにセット Verbose=bool 冗長なメッセージをon/offにセット +V 冗長なメッセージをonにセット -V 冗長なメッセージをoffにセット Draw_Vistas=bool vistasの描画(draw vistas)をon/offに切り替える +UD vistasの描画(draw vistas)をonに切り替える -UD vistasの描画(draw vistas)をoffに切り替える いくつかのシステムではイメージが完了したとき、グラフィック表示はクリアされ、POV-Rayは最終的な統計情報をプリントし終了するためにテキストモードに戻る。通常、グラフィック表示がonの場合、あなたは作業を続ける前にイメージをしばらく見たいだろう。Pause_When_Done =on あるいは +P を使うと、あなたが続けるためにキーを押すまでグラフィックモードのままでPOV-Rayにポーズ(一時停止)させる。デフォルトではポーズしない( -P )。 グラフィック表示を使わない場合、レンダリングの進行をモニターすることが望ましい場合がしばしばある。Verbose =on か +V を使うとレンダリング進行中の冗長なレポートがonになる。これは現在レンダリング中の行番号、現在のフレームに費やされた時間およびその他の情報をレポートする。いくつかのシステムでは、このテキスト情報とグラフィックス表示がコンフリクトしてしまうことがある。表示がonの場合は、これをoffにすることが必要かも知れない。デフォルトの設定はoff( -V )である。 オプション Draw_Vistas =on あるいは +UD はもともとは、POV-Rayのvista(展望)バッファ機能のデバッギングの補助のためのものであった。しかし、これはとても愉快なので残すことに決めた。Vista バッファリングは空間細分割法であり、2次元範囲の境界をビューイング・ウィンドウ上に投影する。POV-Rayは視線光線が、もしあれば、どのオブジェクトにヒットするか素早く決定するために、これらの矩形領域に対する2-D x, yピクセルの位置をテストする。このオプションは用いている2Dの矩形を表示する。デフォルトの設定はoff ( -UD )である。なぜなら、この矩形を描くことは、複雑なシーンではかなりの時間を費やすが、他の重要な目的は持たないからである。 6.2.2.2.3 モザイク・プレビュー Preview_Start_Size=n モザイク・プレビューの開始サイズを n にセットする。 +SPn Preview_Start_Size=nと同じ Preview_End_Size=n モザイク・プレビューの終了サイズを n にセットする。 +EPn Preview_End_Size=nと同じ 通常の場合、あなたがシーンを開発している間、オブジェクトが正しく配置されるか確認するために低い解像度でテストレンダリングを行うだろう。しばしば、この低解像度では満足なディテールを得られず、より高解像度で再びレンダリングしなければならなくなる。モザイク・プレビュー(mosaic preview)と呼ばれる機能があなたのイメージを自動的にいくつかのパスでレンダリングし、この問題を解決する。 初期のパスではモザイク・タイルのような大きなブロックのピクセルで全体のイメージの粗い外観を描く。 続くパスではイメージはより高い解像度を用いてリファイン(refines:高品質化)される。この表示法は低い解像度で非常に素早く全体のイメージを表示し、あなたはシーンに大きな問題がないか見ることができる。イメージがリファイン(refines)されれば、あなたは影やテクスチャのようなより細部に集中できる。あなたは、早めにレンダリングを中断してシーンを修正できるので、問題を見つけるために最高解像度でのレンダリングが終了するまで待たなくても良い。あるいはうまくいっているようなら、高品質、高解像度になるまでレンダリングを続けることができる。 この機能を使うために、あなたは最初に、必要な最も高い解像度になるように高さと幅の値を選択しなければならない。モザイク・プレビューはPreview_Start_Size=n あるいは +SP nを使って、最初のパスでどのくらい大きなモザイク・ブロックを使うかを指定することができる。nは0より大きな2のべき乗の値でなければならない(1, 2, 4, 8, 16, 32, 等。)。もし２のべき乗でないとするとnより小さい最も近い2のべき乗値が代入される。 これはピクセルで数えた正方形の大きさを設定する。値16は最初のパスで16番目毎のすべてのピクセルを16*16ピクセルの正方形で描く。続くパスでは前の値の半分の値が使われる(たとえば 8*8、 4*4 など。) このプロセスは1*1のピクセルにたどり着くか、Preview_End_Size =n あるいは +EP n であなたが指定した値になるまで続けられる。これも、nは0より大きい2のべき乗値でPreview_Start_Size以下でなければならない。それが2のべき乗で無い場合、n未満の最も近い2のべき乗値が代入される。デフォルトの終了値は1である。もし、Preview_End_Sizeに1より大きな値をセットすると、モザイクのパスは1*1になる前に終了するが、POV-Rayは常に1*1で終了する。例えば、あなたが最終イメージの前に、一度だけの 8*8 モザイク・パスが望みならばPreview_Start_Size =8 と Preview_End_Size =8をセットすればよい。 最終的な1*1のパスになるまでファイル出力は行われない。それ以前の段階のパスでは必要な数のピクセルだけがレンダリングされるが、1*1パスではすべてのピクセルを再レンダリングするので、アンチアイリアシングとファイル出力が正しく行われる。これはこのシーンを通常の1*1パスのレンダリングより25%長い時間がかかるようにするので、最終レンダリングにはモザイク・プレビューを使わないように提案する。また、最終パスまでファイル出力がなされないと言うことは1*1パス前に中断されたレンダリングは最初から始めるしか再開する方法が無いことを意味する。 将来のバージョンのPOV-Rayではこれらの非能率と制限を除くために、テンポラリファイルかバッファのシステムが組み込まれるだろう。モザイク・プレビューは現在のところ、テストレンダリングには非常に便利な機能である。 6.2.2.3 ファイル出力オプション Output_to_File=bool ファイル出力を on/offにセット +F ファイル出力を on にセット(デフォルトタイプを使う) -F ファイル出力を offにセット デフォルトでPOV-Rayはイメージファイルをディスクに書き出す。あなたがシーンを開発中でテストレンダリングをしている場合、グラフィックプレビューだけで十分だろう。時間とディスクの動作を節約するためにOutput_to_File =offあるいは -Fにより、ファイル出力をoffにすることができる。 6.2.2.3.1 出力ファイルタイプ Output_File_Type=x ファイル出力フォーマットを'x'にセット +Fxn ファイル出力を on; フォーマットを'x'、デプスを'n'にセット -Fxn ファイル出力をoff;将来の使用のためにフォーマットを 'x'、 デプス(depth)を 'n' Output_Alpha=bool α出力を on/offにセット +UA α出力を onにセット -UA α出力を offにセット Bits_Per_Color=n ファイル出力の bits/colorを 'n' デフォルトのイメージファイルの形式はあなたが使っているプラットホームに依存する。MS-DOSと他の多くのデフォルトは24-bit非圧縮Targa形式である。あなたのプラットフォーム用のドキュメントであなたのデフォルトタイプを調べて欲しい。あなたは、いくつかの異なるファイルタイプの一つをOutput_File_Type =x あるいは+F x で選択することができる。ここで x は以下のどれか一つである... +FC 圧縮 Targa-24 フォーマット(RLE、ランレングス・エンコーディング) +FN 新 PNG (ポータブル・ネットワーク・グラフィックス)フォーマット +FP Unix PPM フォーマット +FS システム特定、 Mac Pict あるいは Windows BMPのような +FT 非圧縮 Targa-24 フォーマット 時代遅れの +FD dump フォーマット と +FR raw フォーマットはPOV-Ray 3.0からはずされている。理由はこれらはめったに使われず、もう必要ないからである。PPM、PNG,およびシステム依存のフォーマットが加えられている。 PPM フォーマットのイメージは非圧縮であり、シンプル・テキスト・ヘッダーを持つ。このことはそれを広く移動できるイメージフォーマットにしている。PNGは新しいイメージフォーマットで、GIFの代用としてだけでなく、その短所を改善するように設計されている。PNGは、レイトレーシングのような高品質アプリケーションのために無損失な最も高い圧縮を提供する。システム特定のフォーマットは使われているプラットフォームに依存し、該当するシステム特定のドキュメンテーションでカバーされている。 これらのフォーマットのほとんどはピクセル当たり24ビットで、赤、緑、青それぞれ8ビットのデータで出力する。PNGはオプションで出力ビットデプス(depth)を赤、緑、青のカラーそれぞれ5から16ビットで、ピクセル当たりのカラー情報を15ビットから48ビットに指定することができる。すべてのフォーマットのデフォルトの出力デプスは8 bits/color (16 百万色が可能)であるが、これをPNGフォーマットのファイルではBits_Per_Color =n か +FN nを指定することにより変更できる。ここで n は必要なビット・デプスである。 8- ないし 16-bit (256 ないし 65536 色)のディスプレイの人々は5 bits/color(32768 色)のような少ないカラーデプスを指定するだけで十分であろうし、またPNGフォーマットの圧縮率も改善されるだろう。10あるいは12のようなより高いビットデプスはビデオや印刷アプリケーションに便利であろう。また、16 bits/colorはグレイスケールのハイトフィールドの出力に適している(ハイトフィールドの詳細はセクション「ハイトフィールド」を参照されたい)。 PNGフォーマットは5から16ビットのα透明度(alpha transparency)のデータを出力でき、Targa フォーマットもまた、8ビットのα透明度(alpha transparency)のデータを出力できるが、上で指定したカラーのビットデプスに依存する。あなたはこのオプションをOutput_Alpha =on あるいは +UAでonに切り替えられる。デフォルトはoffあるいは-UAである。さらなる透明度についての詳細は「アルファチャンネルを使う」を見て欲しい。 様々なビットデプス、αチャンネル、グレイスケールのサポートに加えて、PNGファイルはまた、Display_Gamma 値を保存できるのでイメージはすべてのシステムで正しく表示される(セクション"Display Hardware Settings"を参照)。hf_gray_16グローバル設定は、セクション"HF_Gray_16"で説明されているように、出力ファイルに書かれたデータの形式にも影響を及ぼす。 6.2.2.3.2 出力ファイル名 Output_File_Name=file 出力ファイルをfileにセット +Ofile Output_File_Name=fileと同じ デフォルトの出力ファイル名はシーンの名前から作られるので指定する必要はない。シーン名はドライブ、パス、および拡張子を取り除いた入力名である。例えば、入力ファイル名がc:\povray3\mystuff\myfile.povのの場合、シーン名はmyfileである。正しい拡張子がファイルタイプに従ってシーン名に付けられる。例えばmyfile.tgaあるいはmyfile.pngが使われるだろう。 あなたはOutput_File_Name = file あるいは +Ofileを使って、デフォルトの出力名を無効にすることができる。例えば、 Input_File_Name=myinput.pov Output_File_Name=myoutput.tga 出力ファイル名に"-"が指定された場合(１つのマイナス符号)、イメージは標準出力に書かれる。通常はスクリーンである。望みであれば出力は他のプログラムやGUIにパイプできる。 6.2.2.3.3 出力ファイルバッファ Buffer_Output=bool 出力バッファリングをon/offに切り替える +B 出力バッファリングをonに切り替える -B 出力バッファリングをoffに切り替える Buffer_Size=n 出力バッファのサイズを'n'キロバイトにする。nがゼロなら、 バッファリングしない。 n <システムデフォルトであれば、 システムデフォルトが使われる。 +Bn バッファをonにし、サイズをnにセット -Bn バッファをoffにし、将来でのサイズをnにセットする Buffer_Output および Buffer_Size オプションと +B スイッチは出力ファイルのための大きなバッファの割り当てを可能にする。これはディスク書き込みの時間を削減する。このパラメータが指定されない場合、ピクセルの各行が終了する毎に、その行はファイルに書き出されファイルはフラッシュされる。ほとんどのシステムでは、この動作がディスクへの書き込みを保証するので、システムクラッシュや他の破滅的な出来事が起きても、少なくとも一部の絵は正しく保存され、ディスク上に残っている。デフォルトではバッファは使わない。 6.2.2.4 CPU使用状況ヒストグラム CPU使用状況ヒストグラムはどこでPOV-Rayがレンダリング時間を費やしているかを見つける手段であり、ハイトフィールドを生成する面白い方法と同様である。ヒストグラムは、長方形の格子のブロックに画面を分割する。POV-Rayはイメージをレンダリングするにつれ、各ピクセルをレンダリングするために費やした時間を計算し、この時間を加算し、個々の格子ブロックのためのトータルレンダリング時間とする。レンダリングが終了すると、ヒストグラムは各格子ブロックにおいてピクセルを計算するためにどれだけの時間が費やされたかを示すファイルとなる。 POV-Rayのすべてのバージョンがヒストグラムを生成することができるわけではない。ヒストグラム出力はPOV-Rayが実行されているシステムとファイルタイプに依存する。 6.2.2.4.1 ファイルタイプ Histogram_Type=x ヒストグラムタイプを xにセット(タイプが'X'ならoffにする) +HTx Histogram_Type=xと同じ ヒストグラム出力ファイルタイプは"Output File Type"にあるイメージ出力ファイルとほとんど同じである。利用できるヒストグラムファイルタイプは以下のようである。 +HTC コンマで区切られた値(CSV)しばしばスプレッドシートで使われる +HTN 新PNG (portable network graphics)フォーマットのグレイスケール +HTP Unix PPM フォーマット +HTS システム特定、例えばMac Pict あるいは Windows BMP +HTT 非圧縮 Targa-24 フォーマット (TGA) +HTX ヒストグラムファイルを出力しない +HTCは圧縮Targa-24フォーマットの出力ファイルを作成しないが、代わりにコンマで区切られた各格子ブロックで費やされた時間のリストのテキストファイルが左から右および上から下の順で出力される。CSVファイルへの時間出力の単位はシステムに依存する。CSVファイルの時間の単位についての詳細はシステム特定のドキュメントを参照してほしい。 Targa および PPM フォーマットファイルはPOVのハイトフィールドのフォーマットであり("Height Field"を参照 )、ヒストグラム情報はイメージの赤および緑両方に保存される。このため表示には適さない。ハイトフィールドとして使う場合は、低い値はそのブロックのピクセルの計算にかかった時間が少ないことを示し、高い価はそのブロックにより時間がかかったことを示す。 PNGフォーマットのイメージはグレイスケールのイメージとして保存され、ハイトフィールドの表示と同様にヒストグラムデータの表示に便利である。PNGファイルでは、より暗い(低い)領域はその格子ブロックに少ない時間がかかったことを示し、より明るい(高い)領域がその格子ブロックにより多くの時間がかかったことを示す。 6.2.2.4.2 ファイル名 Histogram_Name=file ヒストグラム名をfileにセットする +HNfile Histogram_Name=fileと同じ ヒストグラムファイル名はヒストグラムデータを書き出すファイルの名前である。ファイル名が指定されない場合はデフォルトのhistgram.extになる。ここでextは前もって指定されたファイルタイプに依存する。ヒストグラム名が指定される場合、ファイル名の拡張子はファイルタイプに一致すべきである。 6.2.2.4.3 格子のサイズ Histogram_Grid_Size=xx.yy ヒストグラム格子をxx × yyにセットする +HSxx.yy Histogram_Grid_Size=xx.yyと同じ ヒストグラム格子のサイズは水平および垂直両方向でのイメージの分割回数を与える。例えば povray +Isample +W640 +H480 +HTN +HS160.120 +HNhistogrm.png は、イメージを 160*120 の格子ブロックに分割する。それぞれのサイズは4*4ピクセルであり、表示やハイトフィールドでの使用に適しているPNGファイルを出力する。 小さな数の格子サイズは、同じ格子ブロックに多くのピクセルが置かれることを意味する。CSV出力では、出力される値の数は指定された格子ブロックの数と同じである。他のフォーマットに対しては、イメージサイズはヒストグラムとレンダリングされたイメージの間の比較を容易にするために、指定された格子サイズではなく、レンダリングされたイメージと同一である。もし、ヒストグラム格子サイズが指定されなければ、デフォルトでイメージと同じサイズになり、したがって、ピクセルあたり1格子ブロックになる。 ヒストグラムは実際の時間ではなく、CPUタイムに基づくものであるから、タスクスイッチングあるいはマルチタスクを行うシステムでは、ヒストグラムはPOV-Rayが与えられた格子ブロックで費やした時間の量を正確に示さないかも知れないということに注意して下さい。その結果、オペレーティングシステムのオーバーヘッドあるいは同時に動作している他のタスクで時間が費やされるかもしれない。このことはヒストグラムが斑、ノイズあるいは大きなスパイクを持つ原因になるだろう。これは格子サイズの減少により、多くのピクセルが与えられた格子ブロックに平均されるので減らすことができる。 6.2.3 シーン構文解析のオプション(Scene Parsing Options) POV-Rayはあなたのシーンファイルを読み込みあなたのシーンの内部モデルを作成するための処理を行う。このプロセスは構文解析(parsing)と呼ばれる。あなたのファイルが解析されるにつれ、別のファイルがその方法に沿って読まれることがある。本セクションでは解析されるものに関するオプション、どこでそれを見つけるか、解析中になされるバージョン特定の仮定は何かをカバーする。 6.2.3.1 入力ファイル名 Input_File_Name=file 入力ファイル名をfileにセット +Ifile Input_File_Name=fileと同じ あなたはたぶんいつでもこのオプションをセットするだろうが、指定しない場合のデフォルトの入力ファイル名はobject.povである。あなたが拡張子を指定しなければ、.povが仮定される。大文字、小文字を区別する(case-sensitive)オペレーティングシステム上では.pov と .POV の両方が試みられる。フルパス指定は使える(MS-DOSシステムでは例えば、+Ic:\povray3\mystuff\BS myfile.povが許される)。入力ファイル名を指定するのに加えて、これはまたシーン名を定める。 シーン名は入力名からドライブ、パスおよび拡張子を取り除いたものである。上の例ではシーン名はmyfileである。この名前はデフォルトの出力ファイル名に使われ、他の場所で参照される。 あなたが、入力ファイル名に"-"を使った場合、入力は標準入力から読み込む。したがって、あなたはプログラムで作られたシーンをPOV-Rayにパイプすることができ、シーンファイル無しでレンダリングできる。 MS-DOSの下では、あなたはこの機能を以下のタイピングで試すことができる。 type ANYSCENE.POV | povray +I- 6.2.3.2 ライブラリ・パス Library_Path=path ライブラリパスリストにパスを加える +Lpath Library_Path=pathと同じ POV-Rayはファイルをカレントディレクトリで探す。ファイルが見つからない場合、あなたが指定した様々なライブラリディレクトリを探すことが必要になる。POV-Rayはあなたのオペレーティングシステムのパスは探さない。カレントディレクトリとあなたがオプションで指定したディレクトリだけを探す。例えば、標準インクルードファイルは通常一つの特別のディレクトリに置かれている。あなたはそこを探すようにPOV-Rayに... Library_Path=c:\povray3\include で告げる。 あなたは、最終パスセパレーター("\" or "/")を最後に付けてはいけない。 複数のこのオプションスイッチの使用はそれ以前の設定を無効にしない。最大10の異なるパスが指定できる。あなたが全く同じパスを二度指定しても、それは1度に数えられる。カレントディレクトリが最初に探され、続いてあなたが指定した順に指示されたライブラリディレクトリが探される。 6.2.3.3 言語バージョン Version=n.n 初期の言語互換性をバージョンn.nにセットする +MVn.n Version=n.nと同じ POV-Ray 3.0に対して多くの言語変更がなされたが、すべてのバージョン2.0の構文とほとんどのバージョン1.0の構文はまだうまく働く。われわれは可能な限り過去のバージョンとの互換性を維持しようとつとめた。2.0で導入された1.0のシーンファイルと互換性のない１つの機能は浮動小数点数式の解析である。Version =1.0 の設定、あるいは +MV 1.0 の使用は数式解析をoffにし、多くの警告メッセージを出すが、ほとんどすべての1.0ファイルはまだうまく働く。2.0 と 3.0 の間の変更はそれほど大規模でない。Version =2.0 の設定は、いくつかの警告メッセージを除くためだけに必要である。当然このオプションのデフォルト設定はVersion =3.0である。 #version 言語命令もまたシーンファイルの内部で何度かモードを変えるために使うことができる。上記のオプションは初期設定のみに影響を与える。言語バージョン命令についての詳細は "Version Directive"を参照して欲しい。 6.2.3.4 ユーザー境界の削除 Remove_Bounds=bool 不必要な境界の削除をon/off +UR 不必要な境界の削除をonに切り替える -UR 不必要な境界の削除をoffに切り替える Split_Unions=bool 境界のある結合の分割のon/offを切り替える +SU 境界のある結合の分割をonに切り替える -SU 境界のある結合の分割をoffに切り替える POV-Rayの初期のバージョンは、光線-オブジェクト交差テストの速度を上げるための自動バウンディング(境界付け)あるいは空間の細分割(sub-division)のシステムを持たなかった。ユーザはレンダリングのスピードアップのためにマニュアル(手動)で境界ボックスを作成しなければならなかった。POV-Ray 3.0 は以前のバージョンに比べてより洗練された自動バウンディングを持つ。多くの場合、旧いシーンのマニュアルバウンディングは新しい自動システムよりも遅い。したがって、POV-Rayはそれが助けになることが分かる場合はマニュアルバウンディングを取り除く。まれに、あなたはマニュアルバウンディングを残したい場合がある。いくつかの旧いシーンはクリッピングを行わなければならなかった場合、不適当にバウンディングを使用している。もし、POV-Rayがそれらのシーンから、その境界(bounds)を取り除くとイメージは正しく見えなくなる。このマニュアル境界の自動削除をoffにするにはRemove_Bounds =offを指定するか、あるいは -URを用いればよい。デフォルトはRemove_Bounds =onである。 判定がまだできない一つの領域はマニュアルで境界づけられた結合(union)の分離である。境界の無い結合は常にそれらを構成している部分に分離され、自動バウンディングがうまく働く。ほとんどのユーザーはそうすると大抵遅くなると言うことを知っているので結合をバウンディングしない。もし、あなたが結合をマニュアルでバウンディングしたいのなら、ほんとにそれをバウンディングしたいのだと思う。安全の理由のため、我々はそのような境界を取り除こうとは思わない。もし、あなたがマニュアル境界を結合から取り除きたいのならばSplit_Unions =on あるいは +SUを使わなければならない。デフォルトはSplit_Unions =offである。 6.2.4 オペレーティング・システムへのシェル・アウト(Shell-out) Pre_Scene_Command=s 全体のシーンの前のコマンドをセットする Pre_Frame_Command=s 各フレームの前のコマンドをセットする Post_Scene_Command=s 全体のシーンの後のコマンドをセットする Post_Frame_Command=s 各フレームの後のコマンドをセットする User_Abort_Command=s ユーザーがPOV-Rayを中断したときのコマンド Fatal_Error_Command=s POV-Rayが致命的なエラーを検出したときのコマンド これらのオプションには + / - スイッチは存在しない。これらはコマンドラインでは使用できない。INIファイルからだけ使用できる。 POV-Rayはいくつかのキーポイントにおいて他のプログラムやバッチファイルを実行するためにシェルアウトする機会を提供する。シェルコマンドはあらゆるシーンで利用可能であるが、通常内部アニメーションループで作られたファイルを処理するために用いられる。CMD は１行のテキストで、プログラムを実行するためにオペレーティングシステムに渡される。例えば Post_Scene_Command=tga2gif -d -m myfile は、シーンのレンダリングが終わった後、myfile.tgaをmyfile.gifに変換するために、ユーティリティtga2gifを -d および -m パラメータで使う。 6.2.4.1 シェルコマンドにおける文字列の代入 あなたがシーン名を変更する度に毎度Post_Scene_Commandを変更するのは厄介であろう。POV-RayはCMD文字列に様々な値を代入することができる。例えば: Post_Scene_Command=tga2gif -d -m %s POV-Rayは%sにコマンド中のシーン名を代入する。シーン名はInput_File_Name あるいは +I 設定から、ドライブ名、ディレクトリおよび拡張子を取り除いたものである。例えば: Input_File_Name=c:\povray3\scenes\waycool.pov はシーン名waycoolになるまで取り除かれ、その結果... Post_Scene_Command=tga2gif -d -m waycool になる。 アニメーションループではフレーム番号を含む完全な出力ファイル名が必要になるかも知れない。文字列 %o は出力ファイル名で置き換えられる。あなたが、出力ファイルをPKZipを使ってzipアーカイブで保存したいとするとしよう。その場合... Post_Frame_Command=pkzip -m %s %o とすることができる。 myscene.povのフレーム12のレンダリングの後、POV-Rayはオペレーティングシステムに" pkzip -m myscene mysce012.tga "を引数にシェルアウトする。pkzipの -m スイッチはmysce012.tgaをmyscene.zipに移動し、ディレクトリから削除する。%oがフレーム番号を含むのはアニメーションループの中の時だけである点を注意する。Pre_Scene_Command と Post_Scene_Command の間にはフレーム番号は無く、したがってオリジナルの番号のないOutput_File_Nameが使われる。ループ内部にない、User_Abort_Command あるいはFatal_Error_Commandは同様に番号のない %o への代入が行われる。 これはよく使う文字列に対して利用できる代入の完全なリストである。 %o 出力ファイル名、拡張子付き、もしあればはめ込まれたフレーム番号付き %s シーン名、入力名からパスと拡張子を除いたもの %n このフレームのフレーム番号 %k このフレームのClock値 %h イメージの高さ(ピクセル数) %w イメージの高さ(ピクセル数) %% 一つの % 符号。 6.2.4.2 シェル・コマンドの順序 ここにアニメーションループでのイベントの順序を示す。アニメーションでないシーンはループが無い事を除き全く同じ方法で動作する。 1) すべてのINIファイルキーワードとコマンドラインスイッチが一度だけ処理される。 2) テキスト出力ストリームをオープンし、もしあればCreate_INIを実行。 3) もしあれば Pre_Scene_Command を実行。 4) フレームを通してのループ(アニメーションでない場合は一度だけ実行)。 a) もしあればPre_Frame_Commandを実行。 b) 全シーンファイルの解析、出力ファイルのオープンと設定の読み込み、ディスプレイをonに切り替え、フレームのレンダリング、全部のオブジェクトおよびテクスチャなどの破壊、出力ファイルを閉じる、ディスプレイを閉じる。 c) もしあればPost_Frame_Commandの実行。 d) すべてのフレームが終了するまで4に戻る。 5) もしあればExecute Post_Scene_Commandを実行。 6) POV-Rayを終了する。 ユーザーが処理を中断した場合、もしあれば、User_Abort_Commandが実行される。ユーザー・アボートは上記のステップ4の解析と、レンダリングの間だけ発生可能である。 もし、致命的エラーが生じた場合、POV-RayはFatal_Error_Commandに注目し、もしあれば実行する。ときどき思いがけないバグやメモリーエラーが全面的なプログラムのクラッシュの原因となる。その場合シェルアウトのチャンスは無い。致命的エラーはスイッチやINIファイルの処理中を含めてあらゆる場所で起こりうる。もし、致命的なエラーがPOV-RayがFatal_Error_Command文字列を読み込んでしまう前に起こったら、当然シェルアウトはできない。 各フレームで全シーンが再解析される点を注意する。将来のPOV-Rayのバージョンでは、一つのフレームから次のフレームのシーンで終わった部分を保持するようになるだろうが、現在は毎回スクラッチ(scratch)から始める。また、Pre_Frame_Command はシーン解析の前に起こる。あなたは、各フレームの前に、これをカスタムなシーン生成ユーティリティを呼び出すために使うかも知れない。このユーティリティは必要であればyour.povあるいは.inc ファイルを書き換えることができる。たぶんあなたは各フレームでイメージマップやハイトフィールドのためのnew.gifあるいは.tgaファイルを生成したくなるだろう。 6.2.4.3 シェルコマンドのリターンアクション(Return Actions) Pre_Scene_Return=s プリ・シーン・リターンアクションのセット Pre_Frame_Return=s プリ・フレーム・リターンアクションのセット Post_Scene_Return=s ポスト・シーン・リターンアクションのセット Post_Frame_Return=s ポスト・フレーム・リターンアクションのセット User_Abort_Return=s ユーザー・アボート・リターンアクションのセット Fatal_Error_Return=s フェイタル・リターンアクションのセット これらのコマンドでは + / - スイッチは利用できない。これらはINIファイルからだけ使える。 ほとんどのオペレーティングシステムはアプリケーションプログラムに、もし何かうまくいかなかった場合エラーコードを返させることができる。POV-Rayがシェルコマンドを実行している場合、このシェルプロセスからのエラーコードを使って、そのコードが0か0でないかに応じて適当な動作をさせることができる。POV-Ray自身もそのようなコードを返す。成功すれば0、致命的エラーなら1そしてユーザー・アボートでは2である。 その動作は別々に、.._Return =sオプションでの１文字で設定される。可能な動作は: I そのコードを無視する S １つのステップをスキップする A すべてのステップをスキップする Q 即座に POV-Ray を終了する U POV-Rayのユーザ・アボートを生成する。 F POV-Rayの致命的エラーを生成する。 例えば、もしあなたのPre_Frame_Commandがハイトフィールドを生成するプログラムを呼び出し、そのユーティリティーが失敗してゼロでない値を返す。 われわれはたぶんPOV-Rayにもまたアボートして欲しいだろう。 Pre_Frame_Return=F はPOV-RayにPre_Frame_Commandがゼロでない値を返した場合、致命的な中止(fatal abort)を行わすようにできる。 ときどき外部プロセスからのゼロでないリターンコードが役立つ場合がある。あなたが、フレームが既にレンダリングされているかどうかテストしたいものとする。あなたは、もしフレームが既にレンダリングされていれば、そのフレームをスキップするために、S動作を用いることができる。ほとんどのユーティリティはファイルが見つからなければエラーをリポートする。例えばコマンドpkzip -v myscene mysce012.tga は、あなたがファイルmysce012.tgaのためにmyscene.zipのカタログを見たいという事をpkzipに伝える。もしアーカイブの中にそのファイルが存在しなければpkzipはゼロでない値を返す。 しかし、もしそのファイルがあれば、われわれはスキップしたい。したがって、ゼロならスキップしてゼロでなければスキップしないように動作を逆にする事が必要となる。動作の引き金となるゼロとゼロでないのの反転はその前に"-"符号を先行させれば良い(多くのプログラミング言語で否定演算子として用いられているので"!"もまた働く)。 Pre_Frame_Return= S はコードがエラー(ゼロでない値)を示せばスキップし、エラーがなければ(ゼロ)正常に進む。Pre_Frame_Return =-S はエラーがなければ(ゼロ)スキップし、エラーならば(ゼロでない値)正常に進む。 すべてのシェルコマンドに対するデフォルトは I で、たとえ何であってもリターン動作は無視される。 POV-Rayはシェルコマンドの前に何をしていたとしても単純に進む。他の動作は前後関係(文脈:context)に依存する。あなたは以前のセクションのアニメーション・ループ・シーケンスのチャートを再び参照しても良い。それぞれのシェルに対する動作は以下のようなものである。 User_Abort_Commandからのリターンにおいて、引き金となる動作があって、あなたが指定したものが... F だと、このユーザー・アボートは致命的エラーに代えられる。もし あれば、Fatal_Error_Commandを実行し、エラーコード1でPOV-Rayを 終了する。 S, A, Q, あるいは U だと、ユーザー・アボートで進み、エラーコード2でPOV-Ray を終了する。 Fatal_Error_Commandからのリターンは何であっても致命的エラーで進む。エラーコード1でPOV-Rayは終了する。Pre_Scene_Command、Pre_Frame_Command、Post_Frame_CommandあるいはPost_Scene_Commandsからのリターンにおいて、引き金となる動作があって、あなたが指定したものが... F だと、致命的エラーを生成する。もしあれば、Fatal_Error_Commandを実行する。エラーコード1でPOV-Rayを終了する。 U だと、ユーザー・アボートを生成する。もしあれば、User_Abort_Commandを実行する。エラーコード2でPOV-Rayを終了する。 Q だと、即座にPOV-Rayをやめる。POV-Rayが実際は走らなかったかのように振る舞う。さらなるシェルは実行しない(Post_Scene_Commandでさえもしない)でエラーコード0でPOV-Rayを終了する。 Pre_Scene_Commandからのリターンにおいて、 引き金となる動作があって、あなたが指定したものが... S だと、すべてのフレームのレンダリングをスキップする。シーンがすべてのフレーム正常に終了したかのように動作する。Pre_Frame_Command や Post_Frame_Commandsは実行しない。もしあればPost_Scene_Commandが実行される。エラーコード0でPOV-Rayを終了する。初期のチャートではこれはステップ#4のスキップを意味する。 A だと、すべてのシーン活動(activity)をスキップする。正確にQによる取りやめと同様に動作する。初期のチャートでは、これはステップ#6までのスキップを意味する。 Pre_Frame_Commandからのリターンにおいて、 引き金となる動作があって、あなたが指定したものが... S だと、このフレームだけがスキップされる。このフレームが決して存在しなかったかのように動作する。Post_Frame_Commandは実行しない。次のフレームを続ける。初期のチャートではステップ#4b と #4cのスキップを意味するが、必要に応じて#4dでループバックする。 A だと、このフレームとすべての残りのフレームのレンダリングをスキップする。シーンのすべてのフレームが正常に完了したかのように動作する。更なるPost_Frame_Commandはいっさい実行しない。もしあればPost_Scene_Commandは実行する。エラーコード0でPOV-Rayを終了する。初期のチャートでは#4の残りをスキップしステップ#5に進むことを意味する。 Post_Frame_Commandからのリターンにおいて、 引き金となる動作があって、あなたが指定したものが... S だと、すべての残りのフレームのレンダリングをスキップする。すべてのフレームが正常に完了したかのように動作する。もしあれば、Post_Scene_Commandを実行する。エラーコード0でPOV-Rayを終了する。初期のチャートではステップ#4の残りをスキップしステップ#5に進むことを意味する。 A はこのシェルコマンドに対しては S と同じ。 Post_Scene_Commandからのリターンにおいて、 引き金となる動作があって、あなたが指定したものが... S あるいは A このシェルコマンドに対してはIと同じ。 6.2.5 テキスト出力 テキスト出力は、POV-Rayが何をしようとしているのか、何をしているのか、何をしたのかをあなたに通知するようにしておく重要な方法である。POV-Ray 3.0では新しく、プログラムはテキストメッセージストリームを7つの別々のストリームに分割する。 いくつかのPOV-Rayのバージョンでは様々なタイプのテキストをカラーコード化する。いくつかのバージョンは、数ページのメッセージをスクロール・バックできる。すべてのバージョンではこれらのテキストストリームのいくつかのオン／オフを切り替え、テキストのコピーを一つないしいくつかのファイルに出力(direct※)させることができる。このセクションではあなたがテキスト出力を制御するためのオプションを詳しく述べる。 (※訳注:directは「出力先の変更」の意であるが単に「出力」と訳す) 6.2.5.1 テキストストリーム POV-Rayは7つの別々のテキストストリーム出力に用いる。いくつかのバージョンでは個々のストリームを特定の色で表示される。これらのストリームからのテキストはそれが適当な場合は常に表示されるので、しばしばテキストが混在する。ストリームの区別はストリームのいくつかをoffに切り替えたり、ストリームのいくつかをテキストファイルに出力する場合だけに必要である。いくつかのシステムでは、個々のスクロールバッファで、別々にストリームに目を通すことが可能である。 それぞれのストリームの説明をここに記す。 BANNER: このストリームはプログラムのサインオン(sign-on)バーナー(banner:見出し)、著作権、貢献者のリストおよびいくつかのヘルプ画面を表示する。これはoffに切り替えたり、ファイルに出力したりはできない。理由は、このテキストの大部分はオプションやスイッチが読み込まれる前に表示されるからである。したがってこれをコントロールるするためにオプションやスイッチを指定できない。ヘルプスクリーンを表示するスイッチはある。それらはセクション"Help Screen Switches"でカバーされている。 DEBUG: このストリームはデバッギング・メッセージを表示する。これは主として開発者のために設計された。しかし、これと他のストリームはシーンファイルの中からのメッセージを表示するためにもユーザーに使われる。この機能の詳細は"Text Message Streams"を見て欲しい。このストリームはoffにしたり、テキストファイルに出力したりできる。 FATAL: このストリームは致命的エラーのメッセージを表示する。このメッセージを表示した後、POV-Rayは終わる。もし、エラーがシーン解析エラーの場合、このエラーの原因となったシーンテキストの2、3行が表示される。このストリームはoffにしたり、テキストファイルに出力したりできる。 RENDER: このストリームはあなたがシーンをレンダリングするためにどんなオプションを指定したかについての情報を表示する。これはシーン名、解像度、アニメーションセッティング、アンチエイリアシングおよび他のすべての主なオプションのフィードバックを含む。このストリームはoffにしたり、テキストファイルに出力したりできる。 STATISTICS: このストリームは一つのフレームがレンダリングされた後の統計を表示する。これはレイトレースされた数、処理にかかった時間、などの情報を含む。このストリームはoffにしたり、テキストファイルに出力したりできる。 STATUS: このストリームはその瞬間POV-Rayが何をしているかのオンライン・ステータス情報を表示する。いくつかのシステムでは、このストリームはスクリーンの最下行のステータス・ラインに表示される。このストリームは一般にその必要がないので、ファイルに出力できない。Verboseオプションあるいは+Vスイッチで表示されたテキストはこのストリームに出力されるので、このステータス・ストリームは部分的にoffにすることができる。 WARNING: このストリームはシーンファイルの解析中の警告(warning)メッセージをあるいは他の警告メッセージを表示する。警告にかかわらず、POV-Rayはシーンをレンダリングし続けることができる。POV-Rayがあなたのシーンについて先に進めるために何らかの仮定をした場合、あなたに通知する。一般にあなたが警告を見た時、あなたはこれが、POV-Rayの将来のバージョンではこの警告された動作が許されなくなるということを意味すると考えなければならない。したがって、あなたが警告メッセージを排除するようにつとめれば、あなたのシーンは今後のPOV-Rayのバージョンでも走らせることができるだろう。このストリームはoffにしたり、テキストファイルに出力したりできる。 6.2.5.2 コンソールテキスト出力 Debug_Console=bool デバッグ情報のテキストのコンソール表示のon/offを切り替える。 +GD Debug_Console=Onと同じ -GD Debug_Console=Offと同じ Fatal_Console=bool 致命的エラーのテキストのコンソール表示のon/offを切り替える。 +GF Fatal_Console=Onと同じ -GF Fatal_Console=Offと同じ Render_Console=bool レンダリング情報のテキストのコンソール表示のon/offを切り替える。 +GR Render_Console=Onと同じ -GR Render_Console=Offと同じ Statistic_Console=bool 統計情報のテキストのコンソール表示のon/offを切り替える。 +GS Statistic_Console=Onと同じ -GS Statistic_Console=Offと同じ Warning_Console=bool 警告のテキストのコンソール表示のon/offを切り替える。 +GW Warning_Console=Onと同じ -GW Warning_Console=Offと同じ All_Console=bool デバッグ、致命的、レンダリング、統計および警告テキストのコンソール表示すべてのon/offを切り替える。 +GA All_Console=Onと同じ -GA All_Console=Offと同じ あなたは、デバッグ、致命的、レンダリング、統計および警告テキストストリームのコンソール出力を抑制しても良い。例えばStatistic_Console =offオプションあるいは-GSスイッチは統計ストリームをoffに切り替える。onあるいは+GSを使えば再びonに切り替えられる。あなたはまた、5つすべてのこれらのストリームをAll_Consoleオプションか +GA スイッチを使うことで一度にonあるいはoffにできる。 これらのオプションは指定されると直ちに効果を及ぼす点を注意する。明らかに、オプションが読まれる前に起こったエラーおよび警告メッセージは影響されない。 6.2.5.3 テキストストリームのファイルへの出力(Directing) Debug_File=true デバッグ情報のテキストをDEBUG.OUTにエコーする Debug_File=false デバッグ情報のファイル出力をoffにする Debug_File=file デバッグ情報のテキストをfileにエコーする +GDfile Debug_Console=On, Debug_File=fileの両方 -GDfile Debug_Console=Off, Debug_File=fileの両方 Fatal_File=true 致命的エラーのテキストをFATAL.OUTにエコーする Fatal_File=false 致命的エラーの出力をoffにする Fatal_File=file 致命的エラーの情報のテキストをfileにエコーする +GFfile Fatal_Console=On, Fatal_File=fileの両方 -GFfile Fatal_Console=Off, Fatal_File=fileの両方 Render_File=true レンダリング情報のテキストをRENDER.OUTにエコーする Render_File=false レンダリング情報のファイル出力をoffにする Render_File=file レンダリング情報のテキストをfileにエコーする +GRfile Render_Console=On, Render_File=fileの両方 -GRfile Render_Console=Off, Render_File=fileの両方 Statistic_File=true 統計情報のテキストをSTATS.OUTにエコーする Statistic_File=false 統計情報のファイル出力をoffにする Statistic_File=file 統計情報のテキストをfileにエコーする +GSFile Statistic_Console=On, Statistic_File=fileの両方 -GSFile Statistic_Console=Off, Statistic_File=fileの両方 Warning_File=true 警告情報のテキストをWARNING.OUTにエコーする Warning_File=false 警告情報のファイル出力をoffにする。 Warning_File=file 警告情報のテキストをfileにエコーする +GWfile Warning_Console=On, Warning_File=fileの両方 -GWfile Warning_Console=Off, Warning_File=fileの両方 All_File=true デバッグ、致命的、レンダリング、統計および警告情報のす べてをALLTEXT.OUTにエコーする All_File=false デバッグ、致命的、レンダリング、統計および警告情報のす べてのファイル出力をoffにする。 All_File=file デバッグ、致命的、レンダリング、統計および警告情報のす べてをfileにエコーする text to file +GAfile All_Console=On, All_File=fileの両方 -GAfile All_Console=Off, All_File=fileの両方 あなたは、デバッグ、致命的、レンダリング、統計および警告テキスト・ストリームについてテキスト・ストリームのコピーをテキストファイルに出力しても良い。例えばStatistic_File =s オプションあるいは+GS s スイッチである。もし文字列 s がtrueか他の有効な真(true)を表す文字列であればそのストリームはデフォルトの名前のファイルにリダイレクトされる。有効な真(true)の値はtrue、yes、onあるいは1である。もし、その値が偽(false)であればテキストファイルの出力はoffになる。有効な偽(false)の値はfalse, no, off および 0である。他のすべての指定された文字列は出力ファイル名に変換され、ファイル出力はonになる。 同様に、あなたはこのようなtrue、falseあるいはファイル名の文字列をスイッチの後に+GS fileのように指定することができる。あなたはまた、5つすべてのストリームを同一のファイルに、All_File オプションあるいは +GA スイッチで出力することができる。あなたは2つまたはそれ以上のストリームに同じファイルを指定してはいけない。なぜなら、POV-Rayは同じファイルを2度オープンあるいはクローズしようとして失敗する。 これらのオプションは指定されると直ちに効果を及ぼす点を注意する。明らかに、オプションが読まれる前に起こったエラーおよび警告メッセージは影響されない。 6.2.5.4 ヘルプ・スクリーン・スイッチ +H oあるいは +? このスイッチだけがある場合、ヘルプスクリーン0を表示する。 +H0 から +H8 このスイッチだけがある場合、ヘルプスクリーン0から8を表示する。 +?0 から +?8 +H0 から +H8と同じ 注意:これらのオプションと等価なINIスタイルはない。 MacやWindows用のようなPOV-Rayのグラフィック・インターフェース版では拡張されたオンラインヘルプがある。他の版のPOV-Rayは二、三のクイックリファレンス・ヘルプスクリーンを持つだけである。+? スイッチ、オプショナルな１文字の0から8の数字が続く、はこれらのヘルプスクリーンをBannerテキストストリームに表示する。ヘルプスクリーンの表示の後、POV-Rayは終了する。なぜなら、いくつかのオペレーティングシステムは、あなたが+Hスイッチも使うかもしれないコマンドラインスイッチにクエスチョンマークを許さないからである。このスイッチはまた、イメージの高さをピクセルで指定するためにも使われるということに注意して欲しい。したがって +H スイッチは、コマンドラインでスイッチの後の値が8以下の場合だけヘルプスイッチとして変換される。 6.2.6 トレーシング・オプション 光線を追跡する方法は1つだけではない。ときどきそれは品質と速度のトレードオフとなる。ときどき、トレーシングをより速くするために設計されたオプションが物事を遅くすることもある。本セクションでは該当する速度と品質(Quality)の設定でどのように光線を追跡するかをPOV-Rayに告げるオプションをカバーする。 6.2.6.1 クオリティの設定 Quality=n クオリティ値を nにセットする (0 <= n <= 11) +Qn Quality=nと同じ Quality =n オプションと +Q n スイッチでイメージのレンダリング・クオリティを設定できる。あなたはテストレンダリングのために、低い値のクオリティを選択しても良いし、最終のレンダリングではそれを上げても良い。クオリティの調整は通常なされる計算のいくつかを除くことによりなされる。例えば、4未満の設定は影(shadows)のレンダリングを行わない。8未満の設定は反射や屈折を使わない。値は以下のクオリティ・レベルと対応する: 0,1 単にクイックカラーだけを示す。完全な環境照明だけを用いる。クイック カラーは5あるいはそれ未満だけで用いられる。 2,3 指定された拡散(diffuse)および環境(ambient)照明を用いる。 4 影をレンダリングするが、拡張照明は用いない。 5 拡張照明を用いて、影をレンダリングする。 6,7 テクスチャパタンを計算する。 8 反射、屈折および透過(transmitted)光線を計算する。 9 ハローを計算する。 6.2.6.2 ラディオシティの設定 +QR ラディオシティをonに切り替える -QR ラディオシティをoffに切り替える(訳注:原文ではonになっている) ラディオシティ(Radiosity)は相互反射(inter-reflection)の拡散光を計算する付加的な計算である。これはきわめて遅い計算であり、幾分実験的である。ラディオシティの計算をどのように行うかを制御するパラメータはglobal_settings {radiosity {... }}ステートメント(構文)の中で指定される。さらに詳しくは"Radiosity"を参照されたい。 6.2.6.3 自動バウンディングの制御(Automatic Bounding Control) Bounding=bool バウンディングを on/offに切り替える +MB バウンディングを on; しきい値 25あるいはそれ以前の量 -MB バウンディングを offに切り替える Bounding_Threshold=n バウンディングしきい値を nにセット +MBn バウンディングを on; 境界となるしきい値を n -MBn バウンディングを off; 将来のためのしきい値を n Light_Buffer=bool ライトバッファをon/offに切り替える +UL ライトバッファをonに切り替える -UL ライトバッファをoffに切り替える Vista_Buffer=bool ビスタバッファをon/offに切り替える +UV ビスタバッファをonに切り替える -UV ビスタバッファをoffに切り替える POV-Rayは、光線-オブジェクトの交差テストの速度を上げるために様々なな空間細別システム(spatial sub-division systems)を使う。プライマリー(主)システムは、ネストしたバウンディングボックス(bounding box)の階層(hierarchy)を用いる。このシステムは、シーンの中のすべての有限オブジェクトを木のような階層に配置した見えない長方形のボックスに区画する。バウンディングボックス内のオブジェクトをテストする前に、木を下り、境界が光線にヒットされたオブジェクトだけがテストされる。これにより、大いにレンダリング速度を改善することができる。しかし、ほんの数個のオブジェクトしかないシーンに対しては、バウンディングシステムを用いることによるオーバーヘッド(経費)がその価値をなくす。Bounding=off オプションあるいは -MB スイッチにより強制的にバウンディングをoffにできる。デフォルト値はonである。 あなたは、Bounding_Threshold =n あるいは +MB n スイッチで、バウンディングが用いられる前に必要な最小限のオブジェクト数をセットできる。デフォルトは+MB 25で、あなたのシーンが25より少ないオブジェクトしか持たない場合は、オーバーヘッドがその価値をなくすため、POV-Rayが自動的にバウンディングをoffにする。通常+MB 5のようなより低いしきい値を用いることは良い考えである。 その上に、POV-Rayはビスタ(vista:見通し)バッファとライト(light:光)バッファとして知られているさらに速度を上げるためのシステムを使う。これらのシステムはバウンディングがonで、バウンディングのしきい値に合うだけの十分な数のオブジェクトがある場合だけ働く。ビスタバッファはバウンディングボックスの階層をスクリーンに投影し、その階層内のそれぞれのエレメントでカバーされる長方形領域を決定することにより作成される。与えられたピクセルを四角形が囲むオブジェクトだけが、主視線光線(viewing ray)によりテストされる。ビスタバッファは透視投影(perspective)および直投影(orthographic)だけのカメラとともに使用できる。なぜなら、それは固定視点と合理的な投影をあてにするからである。(つまり、直線は投影の後で、また直線のままでなければならない)。 ライトバッファは、各光源を仮想的ボックスに入れて、バウンディングボックスの階層を、その6つの側面それぞれに投影することによってつくられる。これは固定した光源をあてにするため、ライトバッファをエリア(面)光に用いることはできない。 反射光および透過(transmitted)光はライトおよびビスタバッファの利点を取らない。 デフォルト設定はVista_Buffer =on あるいは +UV および Light_Buffer =on あるいは +ULである。この機能をoffにするオプションはこれらの機能の有用性を示したり、これらのバウンディングシステムに存在するかも知れない予期せぬバグから防御するために利用できる。 一般に、すべての有限オブジェクトと有限オブジェクトのCGSの多くのタイプはこのバウンディングシステムに正しく応答する。これに加えて、ブロブ(blobs)とメッシュは付加的な内部バウンディングシステムを用いる。これらのシステムは上記のスイッチには影響されない。それらは適当な構文を用いてoffに切り替えることができる。(詳しくは "Blob" と "Mesh" を参照)。 テキストオブジェクトはバウンディングポックス階層を用いてバウンディング(bounded)されたそれぞれの文字に分解される。有限および無限のオブジェクトを組み合わせたいくつかのCGSはまた、自動的にバウンドされる。あなたが多くの無限オブジェクトを使う場合を除き、初期のバージョンのPOV-Rayで必要だったようなマニュアル・バウンディング・オブジェクトを追加することは滅多に必要ないということが最終結果である。 6.2.6.4 アンチエイリアシング(Anti-Aliasing:aa)オプション Antialias=bool アンチエイリアシング(aa)のon/offを切り替える +A aaをonに、しきい値を0.3あるいはそれ以前の量にする -A アンチエイリアシングをoffに切り替える Sampling_Method=n aa-サンプリング法をセットする(1 か 2) +AMn Sampling_Method=nと同じ Antialias_Threshold=n.n アンチエイリアシングしきい値をセットする +An.n aaをonに、aa-しきい値をn.n -An.n aaをoffに(将来でのaa-しきい値をn.n) Jitter=bool aa-jitterの on/offをセット +J aa-jitterを onに、 1.0 かそれ以前の量で -J aa-jitterを offにセット Jitter_Amount=n.n aa-jitterの量をn.nにセット。もし n.n <= 0なら aa-jitterはoffにセット +Jn.n aa-jitterを onにセット; jitterの量をn.nに。もし、 n.n <=0 ならaa-jitterはoffにセット -Jn.n aa-jitterを offに (将来のjitter量をn.nに) Antialias_Depth=n Sets aa-depth (1 <= n <= 9) +Rn Antialias_Depth=nと同じ レイトレーシングプロセスは、要するに、典型的なピクセル当たり一つのサンプルの、イメージの離散的なデジタルサンプリングである。そのようなサンプリングは様々なエラーを導く。それらには、ぎざぎざ、傾斜あるいは曲がった線の階段状の外観、細い線が切れて見えること、干渉によるモアレパターン、失われた細部やオブジェクトの消失等がある。これらは小さすぎるために隣り合うピクセルの間に属するのだ。これらのエラーの原因となる効果は、エイリアシング(aliasing)と呼ばれる。 アンチエイリアスは、イメージのそのようなエラーを排除したり、それらの負の影響を減らすのを援助するために使われるテクニックである。一般に、アンチエイリアシングはレイトレースされたイメージをスムーズに見えるようにする。Antialias =on オプションあるいは +A スイッチはPOV-Rayのアンチエイリアシングシステムをonにする。 アンチエイリアシングがonの場合、POV-Rayは各ピクセルへの視線光線(viewing ray)を一つより多く発射し、そして、ピクセルの見かけの色を決定するために結果を平均することによってこのエラーを減らそうとする。このテクニックはスーパーサンプリング(super-sampling)と呼ばれ、最終イメージを改善することができるが、より多くの計算がなされるため、シーンをレンダリングするのに要求される時間は徹底的に増加する。 POV-Rayはあなたに2つの異なるスーパーサンプリング法を用いるためのオプションを提供する。Sampling_Method =n オプションあるいは +AM n スイッチは非適合の(non-adaptive)スーパーサンプリング(方法1)か適合(adaptive)スーパーサンプリング(方法 2)かを選択する。このモードの一つを選択してもアンチエイリアシングはonにならない。それは +A コマンドラインスイッチかAntialias =on オプションを用いてなされなければならない。 デフォルトでは非適合法( +AM 1)であり、POV-Rayは最初に1ピクセル当たり1光線でトレースする。もし、ピクセルの色がその隣(左あるいは上)の色としきい値(threshold)以上異なれば、そのピクセルは与えられた固定数の付加光線でシュートすることによりスーパーサンプリングされる。デフォルトのしきい値は0.3であるが、Antialias_Threshold =n.nオプションを用いることにより変更できる。このスイッチが使われるとき、しきい値は+Aにオプションとして続けて指定する。例えば+A 0.1はアンチエイリアシングをonに切り替え、しきい値を0.1にセットする。 しきい値との比較は以下のように計算される。もし r_1、g_1、b_1およびr_2、g_2、b_2が2つのピクセルのrgb成分であれば、2つのピクセルの差は以下のように計算される。 diff = abs(r1-r2) + abs(g1-g2) + abs(b1-b2)。 この差がしきい値よりも大きければ両ピクセルはスーパーサンプリングされる。rgbの値は0.0 から 1.0の範囲であるから、最も多いピクセルの差は3.0である。もしこのアンチエイリアシングしきい値が0.0であれば、すべてのピクセルがスーパーサンプリングされる。もしこのしきい値が 3.0 であればアンチエイリアシングはなされない。低いしきい値は多くのアンチエイリアシングと遅いスピードを意味する。アンチエイリアシングは粗いドラフトではなく最終バージョンの絵に用いてほしい。コントラストが低すぎる場合はしきい値が低すぎるのかも知れない。高いコントラストの絵は高い許容限界値により得られる。良い値は0.2 から 0.4のあたりであろう。 非適合法(non-adaptive method)を使用している場合、デフォルトのスーパーサンプルの数は9/ピクセルであり、3*3格子の上に位置する。Antialias_Depth =n オプションあるいは+R nスイッチはスーパーサンプルされるピクセルのためにとられるサンプルの行と列の数をコントロールする。例えば +R 4 は 4*4=16 サンプル/ピクセルの値を与える。 二番目の、適合スーパーサンプリング(adaptive super-sampling)法はそれぞれのピクセルの角の4つの光線をトレースすることから始める。結果の色がしきい値の量より多く異なれば、追加のサンプルがとられる。これが再帰的になされる。つまり、そのピクセルは4つのサブ・ピクセルに分割され、別々にトレースされ、さらなる分割のためにテストされる。この方法の利点は、トレースしなければならない光線を減らせることである。隣接するピクセルとサブ・ピクセルの間の共通のサンプルは保存され、光線の再トレーシングを避けるために再使用される。この方法の再帰的な特徴は、それを適合できるようにすることである。つまり、よりスーパーサンプリングが必要そうな部分のピクセルにスーパーサンプリングが集中する(以下の図を見よ)。 図 どのように適合スーパーサンプリングが働くかの例 再分割の最大数は Antialias_Depth =nオプションあるいは+R n スイッチで指定できる。これは非適合法でスーパーサンプルの総数を指定するのとは異なる。ピクセル当たりの最大サンプル数で表した、最大数のn再分割の結果は以下の表で与えられる。 非適合法でのサンプル数/ 適合法でのサンプル数/ スーパーサンプルされる スーパーサンプルされる +Rn ピクセル数 ピクセル数 1 1 9 2 4 25 3 9 81 4 16 289 5 25 1089 6 36 4225 7 49 16641 8 64 66049 9 81 263169 あなたは、適合の場合にサンプルの最大数は、与えられたピクセルに対して、めったに届かないということに注意しなければならない。もし適合法がアンチアイリアシング無しで用いられた場合、各ピクセルはその四すみでトレースされた光線の平均になる。多くの場合、再帰レベルは3で十分である。 エイリアシング・アーチファクト(artifacts)を減少させる別の方法はサンプリングプロセスにノイズ(noise)を導入することである。これはジッタリング(jittering)と呼ばれ、人間の視覚が規則的なパターンよりもノイズをより多く許容するためにうまく働く。アンチエイリアシングが使われている場合、スーパーサンプリングの位置がわずかの量だけ踊らされる(jittered)あるいはくねくね動かされる(wiggled)。ジッタリングはデフォルトで使用されるが、Jitter =off オプションあるいは -J スイッチでoffに切り替えられる。ジッタリングの量はJitter_Amount =n.n オプションでセットできる。スイッチを用いる場合はジッタリングのスケールを+Jスイッチの後ろに指定することもできる。例えば、 +J 0.5 は標準の半分のジッタを使う。デフォルトの量である1.0は最大のジッタであり、すべてのスーパーサンプルがオリジナルのピクセルの内部に残ることを保証する。ジッタリングのノイズはランダムで繰り返し可能でないのでアニメーション・シーケンスではアンチエイリアスしたピクセルがフレームからフレームにうるさく変化し揺らめくので、ジッタを使うのは避けるべきである。 アンチエイリアシングが使われない場合、スーパーサンプリング方法の指定によらず、ピクセルあたり1つのサンプルがとられる。 7 シーン記述言語(Scene Description Language) シーン記述言語はあなたに世界を記述するための読みやすくて便利な方法を与える。ファイルは、あなたの好みのエディタを使って、アスキーテキストでつくられる。入力ファイル名は、Input_File_Name =file オプションか +I file スイッチを使って指示される。デフォルトで、ファイルは拡張子.povを持つ。POV-Rayは、ファイルを読んで、シーンの内部モデルを作成することにより、それを処理し、それからシーンをレンダリングする。 シーンの全構文は、任意の数の以下に示す項目を任意の順序で含むファイルである。 言語命令 camera{ カメラ項目 } オブジェクト構文 大気構文 global_settings { グローバル項目 } 詳細は 「言語命令」、「オブジェクト」、「カメラ」、「大気の効果」および「グローバル設定」をご覧下さい。 7.1 言語の基礎 POV-Ray言語は、識別子、予約キーワード、浮動小数点数式、文字列、特別なシンボルとコメントから成る。POV-Rayシーンファイルのテキストは、自由形式(フリーフォーマット)である。あなたの望みに合わせて、構文(ステートメント)を別々の行、あるいは同じ行に書いてもよい。キーワードや識別子を分割しない限り、ブランク行、余白あるいは字下げを付け加えてもよい。 7.1.1 識別子とキーワード POV-Rayは、後の利用のためにシーンファイルの中で識別子を定義することを許す。識別子は、1〜40文字の長さである。それは大・小英文字、0から9までの数字、アンダースコア文字("_")からなる。最初の文字は英文字でなければならない。識別子の宜言については、後にカバーされる。 POV-Rayには、下記にリストされるたくさんの予約キーワードがある。 aa_level fog_offset reciprocal aa_threshold fog_type recursion_limit abs frequency red acos gif reflection acosh global_settings refraction adaptive glowing render adc_bailout gradient repeat agate granite rgb agate_turb gray_threshold rgbf all green rgbft alpha halo rgbt ambient height_field right ambient_light hexagon ripples angle hf_gray_16 rotate aperture hierarchy roughness arc_angle hollow samples area_light hypercomplex scale asc if scallop_wave asin ifdef scattering asinh iff seed assumed_gamma image_map shadowless atan incidence sin atan2 include sine_wave atanh int sinh atmosphere interpolate sky atmospheric_attenuation intersection sky_sphere attenuating inverse slice average ior slope_map background irid smooth bicubic_patch irid_wavelength smooth_triangle black_hole jitter sor blob julia_fractal specular blue lambda sphere blur_samples lathe spherical_mapping bounded_by leopard spiral box light_source spiral1 box_mapping linear spiral2 bozo linear_spline spotlight break linear_sweep spotted brick location sqr brick_size log sqrt brightness looks_like statistics brilliance look_at str bumps low_error_factor strcmp bumpy1 mandel strength bumpy2 map_type strlen bumpy3 marble strlwr bump_map material_map strupr bump_size matrix sturm camera max substr case max_intersections superellipsoid caustics max_iteration switch ceil max_trace_level sys checker max_value t chr merge tan clipped_by mesh tanh clock metallic test_camera_1 color min test_camera_2 color_map minimum_reuse test_camera_3 colour mod test_camera_4 colour_map mortar text component nearest_count texture composite no texture_map concat normal tga cone normal_map thickness confidence no_shadow threshold conic_sweep number_of_waves tightness constant object tile2 control0 octaves tiles control1 off torus cos offset track cosh omega transform count omnimax translate crackle on transmit crand once triangle cube onion triangle_wave cubic open true cubic_spline orthographic ttf cylinder panoramic turbulence cylindrical_mapping pattern1 turb_depth debug pattern2 type declare pattern3 u default perspective ultra_wide_angle degrees pgm union dents phase up difference phong use_color diffuse phong_size use_colour direction pi use_index disc pigment u_steps distance pigment_map v distance_maximum planar_mapping val div plane variance dust png vaxis_rotate dust_type point_at vcross eccentricity poly vdot else polygon version emitting pot vlength end pow vnormalize error ppm volume_object error_bound precision volume_rendered exp prism vol_with_light exponent pwr vrotate fade_distance quadratic_spline v_steps fade_power quadric warning falloff quartic warp falloff_angle quaternion water_level false quick_color waves file_exists quick_colour while filter quilted width finish radial wood fisheye radians wrinkles flatness radiosity x flip radius y floor rainbow yes focal_point ramp_wave z fog rand fog_alt range すべての予約語は、完全に小文字である。したがってあなたの識別子は少くとも一つの大文字の文字を含むことが望ましい。そうすれば、予約語との衝突を確実に避けることになる。 以下のキーワードは上のリストに含まれる予約キーワードであるが、現在はPOV-Rayで使われていない。しかし、予約のままにしておく。 bumpy1 test_camera_1 bumpy2 test_camera_2 bumpy3 test_camera_3 incidence test_camera_4 pattern1 track pattern2 volume_object pattern3 volume_rendered spiral vol_with_light 7.1.2 コメント コメントは、シーンファイルを読んだり、理解するのがより簡単にするために挿入されるシーンファイルの中のテキストである。それらは、レイトレーサーによって無視されるが、あなたの参考のためのものである。POV-Rayには2つのタイプのコメントがある。 一行のコメントのためには2つのスラッシュが使われる。行中のダブルスラッシュ（//）の後はレイトレーサーによってすべて無視される。例えば: // この行は無視される 以下のように、コメントの前に、同じ行でシーンファイル情報を書くことができる: object { FooBar } // これはオブジェクトである 別のタイプのコメントは、複数の行のために使われる。それは"/*"で始まり、"*/"で終わる。両者の間にあるすべてのものは無視される。例えば: /* これらの行は レイトレーサー により 無視される */ これは、シーンファイルから要素を一時的に取り除きたいときに便利である。/*... */コメントは別の// コメントを含む行をコメントアウトできる。このようにシーンの一部を一時的に、あるいは永久にコメントアウトするのに使える。 /*... */コメントはネストすることができる。以下は正当である: /* これはコメントである // これも /* これもまた */ */ 惜しげなく、そして気前良くコメントを使ってくさだい。たくさん使うことにより、実際にシーンファイルの読みやすさが改善されます。 7.1.3 浮動小数点数式 POV-Ray言語の多くの部分で、あなたは一つあるいはそれ以上の浮動小数点数を指示することを要求される。浮動小数点数は、小数点をもつ数である。浮動小数点数は、リテラル(文字どおりのもの)、識別子あるいは浮動小数点数値を返す関数を使って指示することもできる。また、いろいろなよく知られている演算子を使って、これらを組合せ、とても複雑な浮動小数点数式を作成することもできる。POV-Rayが整数値を必要とする所で、浮動小数点数値を指示することは許される。それは整数に切り捨てられる。POV-Rayが論理値、あるいは、boolean値を必要とする時、任意の0でない浮動小数点数は真(true)、0は偽(false)と解釈される。丸め誤差を条件として浮動小数点数比較を行うので、boolean関数を実行時、POV-Rayは極端にゼロに近い値を偽として受け入れる。典型的に、前もってセットされた値εより絶対値がより小さい値は、論理的式においては偽とみなされる。εの値はシステムに依存するが、一般に1.0e-10のあたりにある。2つの浮動小数点数 aとbが、abs(a-b) <εならば等しいものとみなされる。 7.1.3.1 浮動小数点数リテラル 浮動小数点数リテラル(literals)は、オプションの符号（「＋」、あるいは、「-」）数字、オプションの小数点、さらに数字によって表される。数が整数であるならば、あなたは小数点と続くゼロを省略することもできる。そのすべてが小数部ならば、あなたは先導しているゼロを省略することもできる。とても大きいかとても小さい数のためのPOV-Rayは科学的な表記法をサポートする。以下は、すべて有効な浮動小数点数リテラルである： -2.0 -4 34 3.4e6 2e-5 .3 0.6 7.1.3.2 浮動小数点数識別子 浮動小数点数識別子はシーンファイルをより読みやすくしたり、あるいは、シーンをパラメータ化し、一つの宣言を変更すると多くの値が変更できるようにするために宣言される。識別子は以下のように宣言される。 #declare 識別子 = 式 ここで "識別子"は識別子の40文字以内の名前で、"式"は任意の有効な式で浮動小数点数値として評価される。ここにいくつかの例を示す。 #declare Count = 0 #declare Rows = 5.3 #declare Cols = 6.15 #declare Number = Rows*Cols #declare Count = Count+1 最後の例で示すように、浮動小数点数識別子を再宣言することができ、それ以前に宣言された値をその再宣言で用いても良い。POV-Rayがあなたのために宣言するいくつかの組み込み識別子がある。詳しくは"Built-in Identifiers"を見て欲しい。 7.1.3.3 浮動小数点数演算子 算術浮動小数点数式は、以下の順序で優先する演算子を用いて浮動小数点数リテラル、識別子および関数を用いて作成できる... () 括弧内の式は最初 +A -A !A 単項(unary)マイナス、単項プラスおよび論理"not" A*B A/B 乗除 A+B A-B 加減 関係(Relational), 論理(logical)および条件(conditional)式もまた作成できる。しかし、これのタイプの式は最初に括弧で囲まれなければならないと言う制限がある。ほとんどのコンピュータ言語では押しつけられないこの宣言はPOV-Rayが浮動小数点数とベクトル式の混合を許すために必要である。この括弧無しでは曖昧性の問題がある。上に示したように、括弧は単項論理not演算子 "!"では要求されない。演算子とそれらの優先順序をここに示す。 関係式:オペランドは算術式で結果は常にtrueに対して1、falseに対して0のブール値である。すべての関係式は同じ優先順位(precedence)である。 (A < B) A は Bより小さい (A <= B) A は B以下 (A = B) A と Bは等しい (厳密には abs(A-B)=EPSILON) (A >= B) A は B以上 (A > B) A は Bより大きい 論理式: オペランドはブール値偽の0と真の1にコンバートされる。結果は常にブール値である。すべての論理式は同じ優先順位である。注意：これらはビット演算子ではなく論理演算子である。 (A & B) AとBがともに真の時真、それ以外の時偽 (A | B) AとBのいずれかが真の時、あるいは両方が真の時、真 条件式: オペランド C はブール値であるがオペランド A と B は任意の式で良い。結果はAとBと同じタイプである。 (C ? A : B) もし C ならば A そうでなければ B いろいろな識別子が宣言されていると仮定すると、以下は有効な式の例である... 1+2+3 2*5 1/3 Row*3 Col*5 (Offset-5)/2 This/That+Other*Thing ((This=Thing)?Foo:Bar) 式は最も内部の括弧が先に評価され、単項の+、-、あるいは!、次に乗除、次に加減、関係、論理、条件式の順で左から右へ評価される。 7.1.4 ベクトル式 POV-Rayは、しばしばあなたにベクトルを指示することを要求する。ベクトルは、一そろいの関連した浮動小数点数値である。ベクトルは、リテラル、識別子あるいはベクトル値を返す関数を使って指示することもできる。また、これらをいろいろなよく知られているオペレーターを使った組合せにより、とても複雑なベクトル式を作成することもできる。 POV-Rayのベクトルは2〜5の成分を持つ可能性がある。しかし、ベクトルのほとんどの大多数は3つの成分を持つ。もし、他で指示されなければ、あなたは単語vectorが3つの成分のベクトルを意味すると仮定するべきである。POV-Rayは3D x、y、z座標系中で動作するので、あなたはx、yおよびz値を指示するために3つの成分ベクトルを使うだろう。いくつかの場所でPOV-Rayは、2つの座標だけを必要とする。これらは、UVベクトルと名づけられる2Dベクトルによって、多くの場合指示される。フラクタルオブジェクトは、4Dベクトルを使う。カラー式は、5Dベクトルを使うが、3つ、4つあるいは5つの成分を指示することを許して、指示されない成分のためにはデフォルト値を使う。もし、注意がなければ、2、4、あるいは5成分のベクトルは3Dベクトルと全く同じように働くが、それらは異なる数の成分を持つ。 7.1.4.1 ベクトルリテラル ベクトルは、かぎ括弧<と>によって括弧でくくられる2〜5の浮動小数点数式から成る。項は、コンマによって区切られる。例えば、代表的な3つの成分ベクトルが、ここにある: < 1.0, 3.2, -5.4578 > 成分の間のコンマは、プログラムが、2番目の項が一つの浮動小数点数式3.2-5.4578であり、また3番目の項がないと思わせないようにするために必要である。もし、あなたがFloat expected but '>' found(浮動小数点数値が期待される場所に'>'が見つかった)のようなエラーメッセージを見たときは、たぶんあなたはコンマを忘れているのだ。 時々、POV-Rayはあなたに浮動小数点数とベクトルを並べて指示することを要求する。ベクトル式に対する規則ではベクトルとベクトルあるいは、浮動小数点数とベクトルの混在を許すので、曖昧さが起こるかもしれないときはいつでも、コンマは必要なセパレーターである。例えば<1,2,3>-4 は浮動小数点数とベクトル式の混合演算として評価される。ここでは4が各成分から減じられ、結果は<-3,-2,-1>となる。しかし、コンマが入った <1,2,3>,-4は浮動小数点数が後ろについたベクトルを意味する。 各成分にはすべての浮動小数点数式が許される。例えばは有効なベクトルである。 7.1.4.2 ベクトル識別子 ベクトル識別子はシーンファイルを読みやすくしたり、シーンをパラメータ化するために宣言することもできる。そうすれば、一つの宜言の変更により多くの値を変更できる。識別子は以下のように宣言される... #declare 識別子 = 式 ここで"識別子"は最大40文字の識別子の名前で、"式"はベクトル値として評価される任意の有効な式である。ここにひとつの例がある... #declare Here = <1,2,3> #declare There = <3,4,5> #declare Jump = #declare Route = There-Here #declare Jump = Jump+<1,2,3> あなたがかぎ括弧なしでその名前を使うことによってベクトル識別子を呼び出す点に注意しなさい。最後の例で示すように、あなたはベクトル識別子を再宣言でき、それ以前に宣言された値をその再宣言で用いることができる。POV-Rayがあなたのために宣言するいくつかの組み込み識別子がある。詳細は「組み込み識別子」を見なさい。 7.1.4.3 ベクトル演算子 ベクトルリテラル、識別子および関数は浮動小数点数値と同様に式の中で組み合わせることができる。演算は、成分対成分の原則で実行される。例えば、<1,2,3>＋<4,5,6>は<1+4,2+5,3+6>あるいは<5,7,9>と同じに評価される。他の演算も同様に成分対成分の原則で実行される。例えば(<1,2,3> = <3,2,1>)は、<0,1,0>と評価される。理由は真ん中の成分は等しいが、他はそうでないからである。明らかに、これままったく役に立たない。しかしこれは他のベクトル演算と一貫している。 (C ? A : B)のような条件式ではCが浮動小数点数式であることが要求されるが、 A と B はベクトル式でも良い。結果は、全体の条件文は有効なベクトルとして評価される。例えば、Foo とBarが浮動小数点数だと Foo < Bar ? <1,2,3> : <5,6,7> は、FooがBarより小さければベクトル<1,2,3>を評価し、そうでなければ<5,6,7>を評価する。 あなたは、ベクトルから一つの成分を引用するためにドット演算子を使ってもよい。識別子Spotが以前にベクトルとして定義されていると仮定する。その時、Spot.xはこのx,y,zベクトルの最初の成分である浮動小数点数値である。同様に、Spot.yとSpot.zは2番目と3番目の成分を引用する。Spotが2つの成分のUVベクトルであるならば、あなたは最初と二番目の成分を引用するためにSpot.uとSpot.vを使ってもよかった。4Dベクトルの各浮動小数点数成分を引用するためには.x、.y、.z および.tを使いなさい。また、後にカバーされるカラー式の中でもドット演算子は使われる。 7.1.4.4 演算子プロモーション(Promotion:格上げ) あなたは、成分がすべて同じであるベクトルを定義するために単独の浮動小数点数式を使ってもよい。POV-Rayは、それが特定のタイプのベクトルを必要とする時を知っていて、もしも必要であれば、浮動小数点数をベクトルにプロモートする。例えば、POV-Rayのscale構文は、3成分のベクトルを必要とする。あなたがscale 5を指示するならば、POV-Rayがこれをscale <5,5,5>と解釈する。これはあなたがあらゆる方向に5によって拡大縮小したいことを意味する。 3.0より前のPOV-Rayのバージョンでは、そのような浮動小数点数の使用はscale と turbulenceのようないろいろな限られた場所でのみ許されていた。しかし現在、あなたはどこでもこのトリックを使ってよい。例えば... box{0,1} // これは box{<0,0,0>,<1,1,1>}と同じ sphere{0,1} // sphere{<0,0,0>,1}と同じ 浮動小数点数を2、3、4あるいは5成分のベクトルにプロモートする際、すべての成分はその浮動小数点数値にセットされる。しかし、成分の数の少ないベクトルを高次のベクトルにプロモートする際はすべての残りの成分は0にセットされる。例えばPOV-Rayが4Dベクトルを期待し、あなたが9を指定すれば結果は <9,9,9,9>であるが、もし<7,6>を指定すれば結果は<7,6,0,0>である。 7.1.5 カラー(色)を指定する POV-Rayは、多くの場合あなたにカラーを指定することを要求する。カラーは、5つの値あるいはカラー成分から成る。最初の三つは、赤(red)、緑(green)、青(blue)と呼ばれる。それらはカラーモニターの赤緑青色の蛍光体(phosphors)で用いるような加色系(additive color system)における三原色(primary colors)、赤、緑、青の強度(intensity)を指定する。 4番目の成分はフィルタ(filter)と呼ばれ、物質のフィルタ透明度(filtered transparency:選択的に透過される透明度)の量を指示する。フィルタ透明度のいくつかの現実の例は、ステンドグラス製の窓や、色をつけたセロハンがある。そのようなオブジェクトを通り抜けている光は、その材料が選択的にいずれかの周波数の光を吸収し、他の光は通過させることにより、その該当する色によって色をつけられる。オブジェクトの色は通過する光から差し引かれるので、これは減法的透明度(subtractive transparency)と名づけられる。 5番目の成分は透過(transmit:トランスミット)と呼ばれ、表面を通して透過されるフィルタリングされない(non-filtered)光の量を指定する。フィルタリングされない透明度の現実の例はシースルーの布や、目の細かい網、表面上のほこりである。これらの例では、光のすべての周波数がその表面の小さい穴から通過することができる。通過する光の量は減少するけれども、通過する光の色は変わらない。オブジェクトの色は通過する光に加えられので、これは加法的透明度(additive transparency)と呼ばれる。 POV-Rayの初期のバージョンがフィルタ透明度を指示するためにキーワードalphaを使った点に注意しなさい。しかし、その語はフィルタされない(non-filtered)透明度を記述するために、多くの場合使われる。この理由からalphaはもう使わない。 カラーの5つの成分のいずれもが、通常0.0と1.0の間の範囲にある浮動小数点数値である。しかし、負数を含む任意の値を使ってもよい。 カラーは、ベクトル、浮動小数点数をもつキーワードあるいは識別子を使って指示することができる。また、あなたは、これらをいろいろなよく知られている演算子を使って組合せ、とても複雑なカラー式を作成することもできる。カラーを指示するための構文は、POV-Rayが最初にリリースされてから進化した。我々は、オリジナルのキーワードに基づく構文を維持して、ショートカット(short-cut)ベクトル表記法を付け加えた。新旧構文の両方が受け入れられるけれども、カラー式を作成しているときはベクトル構文を使うのがより簡単である。 7.1.5.1 カラーベクトル カラーベクトルのための構文は以下のものである... color rgb ベクトル3 color rgbf ベクトル4 color rgbt ベクトル4 color rgbft ベクトル5 ここで ベクトル3、ベクトル4およびベクトル5は3、4および5成分の有効なベクトル式である 。例えば color rgb <1.0, 0.5, 0.2> これは、赤い成分が完全な強度の1.0、あるいは、100 %である色を指示する。緑の成分は完全な強度の0.5、あるいは、50 %である、そして、青い成分は完全な強度の0.2、あるいは、20 %である。フィルタおよび透過成分は明示されていないけれども、それらは存在し、それらのデフォルト値0つまり透明性なしにセットされる。 rgbfキーワードは、4成分のベクトルを必要とする。4番目の成分が、フィルタ成分であり、そして透過成分はデフォルトの0である。同様にrgbtキーワードは4成分を必要とし、4番目の値は5番目の成分に移動される。それは透過(transmittance)であるのでフィルタ成分は0にセットされる。 rgbftキーワードは、あなたに5つの成分すべてを指示するすることを許す。内部的には数式において、常に5つすべての成分が使われている。 大抵の状況の下で、キーワードcolorは、任意に省略することもできる。我々はまた、イギリス人やカナダ人の綴りであるcolourをサポートする。ある条件下では、もし、ベクトル式が5成分の式、あるいは、カラー識別子が式にあるならば、その時はrgbtfキーワードは任意である。 7.1.5.2 Colorキーワード カラーを指示する古いキーワードによる方法はまだ役に立ち、そして、多くのユーザはそれをむしろ好む。color vectorのように、あなたはオプショナルなキーワードcolorで始める。これに付加的なキーワードred、green、blue、filterあるいはtransmitが続く。これらの成分キーワードのそれぞれに浮動小数点数式が続く。例えば color red 1.0 green 0.5 これは赤い成分が完全な強度の1.0、あるいは100 %で、緑の成分が完全な強度の0.5、あるいは50 %の色を指定する。blue、filterおよびtransmit成分は明示されないけれど、それらは存在し、それらのデフォルト値0にセットされる。成分キーワードは任意の順序で指定でき、成分が指定されない場合はそのデフォルト値0になる。 7.1.5.3 カラー識別子 カラー識別子はより多くのシーンファイルを読みやすく作るためや、シーンをパラメーター化するために宣言することもできる。そして、一つの宜言の変更により多くの値を変えることができる。カラー識別子は以下のいずれかで宣言される... #declare 識別子 = カラーベクトル #declare 識別子 = カラーキーワード... ここで"識別子"は識別子の名前で40文字以内の長さであり、"カラーベクトル"および"カラーキーワード"は本ドキュメントの前述の2セクションで述べた任意の有効なカラー指定である。ここにいくつかの例がある... #declare White = rgb <1,1,1> #declare Cyan = color blue 1.0 green 1.0 #declare Weird = rgb #declare LightGray = White*0.8 #declare LightCyan = Cyan red 0.6 LightGrayの例で示すように、以前に宣言されたカラーに基づいてカラー式を作成する場合はcolorキーワードは不要である。最後の例では、あなたが、キーワード形式の構文でカラー識別子を使っても良いことを示している。その識別子が他のいずれの成分キーワードよりも最初に来ることを確認して下さい。 浮動小数点数やベクトルのように、あなたはシーン中でカラーを再定義することもできるが、そうする必要があるのはまれなことである。 7.1.5.4 カラーの演算 カラーベクトルは、浮動小数点数やベクトル値と同じように、式の中で結合しても良い。演算は、成分と成分の対応を原則として実行される。例えばrgb <1.0, 0.5 0.2> * 0.9 はrgb <1.0, 0.5 0.2> *<0.9, 0.9, 0.9> あるいは rgb <0.9, 0.45, 0.18>と同じに評価される。他の演算も同様に成分と成分の対応を原則として実行される。 あなたは、カラーから一つの成分を引用するためにドット演算子を使ってもよい。識別子Shadeが以前にカラー(color)として定義されたことを仮定する。その時、Shade.redはShadeの赤成分の浮動小数点数値である。同様に、Shade.green、Shade.blue、Shade.filterとShade.transmitは他のカラー成分の浮動小数点数値を引用する。 7.1.5.5 よくあるカラーの落し穴 カラーの定義方法の多様性と複雑さにより、いくつかのありふれた間違いに至る可能性がある。カラーを指定するとき、考慮すべきいくつかの事項をここに示す。 フィルタ透明度を使う場合、通過して来るカラーは原色成分を掛けられる。例えば、rgb<0.9,0.9,0.9>のようなグレイの光がrgbf <1.0,0.5,0.0,1.0>のようなフィルタを通過する場合、結果はrgb <0.9,0.45,0.0>で、赤(red)が100%通過し、緑(green)は0.9から0.45に半分カットされ青(blue)は完全にブロックされる。ユーザはしばしば、誤ってクリアなオブジェクトを以下で指示する。 color filter 1.0 しかし、これは赤、緑、青の値とも0を意味する。あなたが指定したのは、完全に黒いフィルタで、光は全く通らない。正しい方法は、以下のどちらかである color red 1.0 green 1.0 blue 1.0 filter 1.0 または color transmit 1.0 2番目の例でrgb値が何であるかは問題でない。通過する光のすべては影響されない。 別の落し穴は、colorキーワードを用いたカラー識別子と式の使用である。例えば... color My_Color red 0.5 これは、たとえMy_Colorの赤成分が何であっても0.5の赤成分を代入するがしかし... color My_Color + red 0.5 は0.5をMy_Colorの赤成分に加える。そしてあまり明白ではないが... color My_Color * red 0.5 はあなたの期待するように赤成分を半分にカットする。しかしこれはまた、green、blue、 filter および transmit 成分に0を掛ける!乗算演算子の後ろの式はrgbft<0.5,0,0,0,0> の完全な 5 成分のカラーに評価される。 以下の例では結果としてMy_Colorを変更しない。 color red 0.5 My_Color これは、識別子が完全に以前の値に上書きされるからである。colorキーワードとともに識別子を使う場合、識別子が最初でなければならない。 最後の問題として、いくつかのPOV-Ray構文は、完全なカラー定義を許すが、rgb部分を使うだけである。これらの場合は、カラーが必要とされる所で浮動小数点数を使うことは正当である。例えば: finish { ambient 1 } ambientキーワードはカラー(color)を期待するので、その値1は<1,1,1,1,1>にプロモートされ問題ない。しかし、 pigment { color 0.4 } は正当であるが、それがあなたの意味したものかもしれないし、そうでないかもしれない。この0.4は<0.4,0.4,0.4,0.4,0.>にプロモートされfilterとtransmitは0.4にまたセットされる。これが、おそらくあなたが求めたものである... pigment { color rgb 0.4 } この場合、1つの3成分ベクトルが期待される。したがって0.4は<0.4,0.4,0.4,0.0,0.0>にプロモートされ、filterとtransmitはデフォルトの0となる。 7.1.6 文字列(Strings) POV-Ray言語は、ファイル名、メッセージのためのテキストあるいはテキストオブジェクトのためのテキストで使うために、文字からなる文字列を指定することを要求する。文字列は、リテラル(そのままの文字列)、識別子あるいは文字列値を返す関数を使って指定できる。あなたは、浮動小数点数、ベクトルあるいはカラーで使ったような記号的な演算子から、文字列式を作ることはできないけれども、あなたは文字列関数を使っているいろいろな文字列操作を実行することができる。POV-Rayの文字列のいくつかのアプリケーションは、改行やフォームフィードのような印刷されない書式用の文字を許す。 7.1.6.1 文字列リテラル(literals) 文字列リテラルはは、二重引用符マーク『"』から始まって、最高256文字の印刷可能なアスキー文字が続き、別の二重引用符マークによって終了する。以下はすべて有効な文字列リテラルである: "Here" "There" "myfile.gif" "textures.inc" 7.1.6.2 文字列識別子 文字列識別子はシーンファイルをより読みやすくしたりシーンをパラメータ化し、一つの宣言の変更で多くの値を変更できるようにするために宣言しても良い。識別子は以下のように宣言される... #declare 識別子 = 文字列 ここで"識別子"は40文字までの識別子の名前であり"文字列"は文字列リテラル、文字列識別子、文字列値を返す関数である。ここにいくつかの例がある... #declare Font_Name = "arial.ttf" #declare Inc_File = "myfile.inc" #declare Name = "John" #declare Name = concat(Name," Doe") 最後の例で示すように、あなたは文字列識別子を再宣言することができ、その再宣言の中で先に宣言された値を使っても良い。 7.1.7 組み込み識別子 いくつかの組み込まれた浮動小数点数とベクトル識別子がある。あなたは値を指定したり、式を作成するためにそれらを使うことができる。しかし、あなたはそれらの値を変更するためにそれらを再宣言することはできない。 7.1.7.1 定数値の組み込み識別子(Constant Built-in Identifiers) 大抵の組み込み識別子は、値を決して変えない。まるで以下の行がそれぞれのシーンの先頭にあったように、それらは定義される。 #declare pi = 3.1415926535897932384626 #declare true = 1 #declare yes = 1 #declare on = 1 #declare false = 0 #declare no = 0 #declare off = 0 #declare u = <1,0> #declare v = <0,1> #declare x = <1,0,0> #declare y = <0,1,0> #declare z = <0,0,1> #declare t = <0,0,0,1> 組み込み浮動小数点数識別子piは、円を含む数学式に明らかに役立つ。 組み込み浮動小数点数識別子 on、off、yes、no、trueおよびfalseはブーリアン(論理)定数のために用意されている。 組み込みベクトル識別子 x、y およびz はベクトル式を用いたあなたのシーンの読み安さを格段に改善する。例えば.... plane { y, 1} // 法線ベクトルは明らかに"y"である。 plane { <0,1,0>, 1} // これはわかりにくい。 translate 5*x // "x"方向に5単位平行移動。 translate <5,0,0> // これは少しわかりにくい。 5*xのような式は5 <1,0,0> あるいは <5,0,0>と評価される。 同様に u および v は2Dベクトルで用いられる。4Dベクトルを使う場合、あなたは x, y, z, および tを使うべきで、4Dが要求される場所で用いられた場合、POV-Ray は x, y および z を4Dにプロモートする。 7.1.7.2 組み込み識別子'clock' 組み込み浮動小数点数識別子clockは、POV-Rayでアニメーションを制御するために使われる。いくつかのアニメーションパッケージと違って、POV-Rayのアニメーションシーンの中の動作は、整数フレーム数に依存しない。その代わりあなたは、浮動小数点数識別子clockに基づいてシーンを設計しなければならない。アニメーションでないシーンのためにそのデフォルト値は0であるが、あなたのシーンファイルに一つの浮動小数点数値を渡すために、INIファイルオプションClock=n.nかコマンドラインスイッチ+Kn.nを用いて、任意の浮動小数点数値を設定できる。 別のINIオプションとスイッチは、clockのいろいろな値を使って、フレームのレンダリングを自動的にループ化することによるシーンのアニメーション化に使ってもよい。デフォルトで、clock値は、初めのフレームのための0と最終的なフレームのための1である。すべての残りのフレームは、これらの値の間に差し込まれる。例えば、もし、あなたのオブジェクトが、アニメーションのコース上で一つのフルターン回転させるとすれば、あなたは rotate 360*clock*yを指定することができる。そうすると、clockが0から1に進むにつれ、オブジェクトはy軸まわりで0から360度まで回転する。 フレーム毎にclockの値は変わるけれども、それ(訳注:rotate 360*clock*y)は、シーンの分析の最初から最後まで決して変わらないだろう。 7.1.7.3 組み込み識別子 'version' 組み込み浮動小数点数識別子versionは、バージョン互換性オプションの現在の設定値を持つ。この値のデフォルトは現在のPOV-Rayのバージョン番号3であるけれども、versionの初期値をINIファイルオプション Version=n.n あるいは+MVn.n コマンドラインスイッチで設定できる。これは、POV-Rayにシーンファイルを初期のバージョンのPOV-Rayの構文から解析するように知らせる。 このINIオプションとスイッチは、初期設定に影響を及ぼすだけである。他の組み込み識別子と違って、versionの値は、シーンファイルを通して(途中で)変えても良い。けれども、それを変えるためにあなたは#declareを使わない。#version言語命令が、モードを変えるために使われる。そのような変更が、数回、シーンファイルの中で起こってもよい。 組み込みversion識別子と#version命令で、互換性設定の以前の値を保存して、元に戻すことができる。例えば、mystuff.incがバージョン1のフォーマットであると仮定しなさい。ファイルの先頭にあなたが置くことができるのは: #declare Temp_Vers = version // 以前の値を保存 #version 1.0 // 1.0 モードに変更 ... // バージョン1.0の物は、ここに行く...... #version Temp_Vers // 以前の値を元に戻す 7.1.8 関数 POV-Rayは、浮動小数点数、ベクトルおよび文字列を処理するためにいろいろな組み込み関数を定義する。関数はそれらの戻り値の型でなく、それらの使用法に従ってまとめてリストされる。例えば、vdotは2つのベクトルのドット積を計算するが、たとえそれが一つの浮動小数点数値を返すとしてもベクトル関数にリストされる。 関数呼び出しは、括弧に入れられたパラメータリストが続く関数の名前を指定するキーワードから成る。パラメータは、コンマによって区切られる。例えば: keyword(param1,param2) 関数は浮動小数点数、ベクトル、文字列値に評価し、そのタイプのリテラルや識別子が使われる場所ならどこでも式や構文の中で使うことができる。 7.1.8.1 浮動小数点数関数 (訳注:関数のサンプルはpov3demo\other\float5.pov参照) 以下は、一つ以上の浮動小数点数パラメータをとって浮動小数点数値を返す関数である。AとBが浮動小数点数に評価できる有効な式であると仮定している。主要な目的がより密接にベクトルと文字列に関連している浮動小数点数値を返す他の関数のために「ベクトル関数」と「文字列関数」を見てください。 abs(A): Aの絶対値。Aが負なら-Aをかえし、そうでなければAを返す。 acos(A): Aのアークコサイン。コサイン(cos)がAとなる角度をラジアンで返す。 asin(A): Aのアークサイン。サイン(sin)がAとなる角度をラジアンで返す。 atan2(A,B): (A/B)のアークタンジェント。タンジェント(tan)が(A/B)となる角度をラジアンで返す。もしBが0なら適当な値を返す。通常のatan(A)関数を計算するためにはatan2(A,1)を用いて下さい。 ceil(A): Aのシーリング(Ceiling:切り上げ)。Aより大きい最小の整数を返す。次のより高い整数まで丸める(Rounds up)。 cos(A): Aのコサイン。角度Aの余弦を返す。Aはラジアン。 degrees(A): ラジアンを度に変換する。ラジアン値Aを度で返す。式はdegrees=A/pi*180.0。 div(A,B): 整数除算。(A/B)の整数部。 exp(A): Aの指数関数。eのA乗の値を返す。eは無理数で近似値は2.71828182846の自然対数の底である。 floor(A): Aのフロア(Floor:切り捨て)。Aより小さい最大の整数を返す。次のより低い整数まで丸める(Rounds down)。 int(A): Aの整数部。Aの切り捨てられた整数部分を返す。ゼロの方へ丸める。 log(A): Aの自然対数。eを底とするAの自然対数を返す。eは無理数で近似値は2.71828182846。 max(A,B): A と Bの大きい方の値。AがBより大きければAを返し、そうでなければBを返す。 min(A,B): A と Bの小さい方の値。AがBより小さければAを返し、そうでなければBを返す。 mod(A,B): A modulo B※(Bを法とするAの値)の値。整数除算A/Bの余りを返す。式はmod=((A/B)-int(A/B))*B。(※訳注：原文はA) pow(A,B): べき乗(累乗)。AのB乗を返す。 radians(A): 度をラジアンに変換する。Aを度としてそのラジアン値を返す。式はradians=A*pi/180.0。 rand(A): 正整数Aによって指定されたストリームから、次の疑似乱数を返す。rand()を呼び出す前に乱数ストリームを初期化するためにseed()を呼び出さなければならない。数値は全体として一様に分布する0〜1の間の値である。 seed(A):初期シード(seed)値Aで新しい疑似乱数ストリームを初期化する。このランダムなストリームに対応している数が返される。任意の数の疑似乱数ストリームが以下の例のように使われる: #declare R1 = seed(0) #declare R2 = seed(12345) #sphere { , rand(R2) } 複数の乱数発生器はあなたがオブジェクトのグループをrand()を用いて配置し、rand()をファイルの最初の方の他の場所で、カラーや他のオブジェクトのグループを配置しようとする状況で非常に役立つ。別々のrand()ストリームなしでは、すべてのあなたのオブジェクトはあなたがさらにrand()を呼び出した場合、移動する。これは、とても悩みの種である。 sin(A): Aのサイン。角度Aの正弦を返す。Aはラジアンである。 sqrt(A): Aの平方根。二乗がAとなる値を返す。 tan(A): Aのタンジェント。角度Aの正接を返す。Aはラジアンである。 7.1.8.2 ベクトル関数 以下は、一つ以上のベクトルと浮動小数点数パラメータをとって、ベクトルあるいは浮動小数点数値を返す関数である。これらの関数のすべては、3成分ベクトルだけをサポートする。AとBが3成分ベクトルに評価される有効な式で、Fが浮動小数点数に評価される有効な式であると仮定しなさい。 vaxis_rotate(A,B,F): AをBに関してFだけ回転(Rotate)。ベクトルAによって示された空間の点のx,y,z座標を与え、ベクトルBによって定義された任意の軸についてのその点を回転させる。単位は度で、浮動小数点数値 Fで指定した角度だけ回転する。結果はその点の新しいx,y,z 座標を含むベクトルとなる。 vcross(A,B): AとBのクロス積。2つのベクトルのクロス積となるベクトルを返す。結果のベクトルは2つのオリジナルのベクトルに直交し、その長さはそれらの間の角度に等しい。具体例は動画デモシーンのVECT2.POVを見て欲しい。 vdot(A,B): AとBのドット積。ドット積の浮動小数点数値を返す(しばしばAとBのスカラー積と呼ばれる)。式はvdot=A.x*B.x + A.y*B.y + A.z*B.z。具体例は動画デモシーンのVECT2.POVを見て欲しい。 vlength(A): Aの長さ。ベクトルAの長さを浮動小数点数値で返す。2点間の距離の算出に使える。Dist=vlength(B-A)。式は、vlength=sqrt(vdot(A,A))。 vnormalize(A): ベクトルAを正規化する。Aと同じ方向の単位ベクトルを返す。式は、vnormalize=A/vlength(A)。 vrotate(A,B): A を原点に関してB回転する。ベクトルAによって示された空間の点のx,y,z座標を与え、その点を原点に関して指定されたベクトルBの量だけ回転する。x軸に関して度を単位とする浮動小数点数値B.xだけ回転する。同様にB.y および B.z は度を単位としてy-軸およびz-軸に関する量を指定する。結果はその点の新しいx,y,z座標を持つベクトルになる。 7.1.8.3 文字列関数 以下は、一つ以上の文字列および浮動小数点数パラメータをとって、文字列か浮動小数点数値を返す関数である。S1とS2が有効な文字列であると仮定しなさい、そして、そのA、LおよびPは浮動小数点数に評価され有効な式である。 asc(S1): S1のASCII値。S1の最初の文字のASCII値を0から255の整数値で返す。例えば、asc("ABC")は文字"A"の値である65になる。 chr(A): ASCII値がAとなる文字。1文字の文字列を返す。文字のASCII値は整数Aで指定される。Aの範囲は0から255でなければならない。例えばchr(70)は文字列"F"である。もしあなたがテキストオブジェクトのレンダリングにおいてchr()を使う場合、レンダリングされる文字の値が A>127の文字は使う(TTF)フォントに依存するということを知っていなければならない。多くの(TTF)フォントはLatin-1 (ISO 8859-1)文字セットを使うがすべてがそうではない。 concat(S1,S2,[S3...]):文字列S1とS2を連結する。戻される文字列はすべてのパラメータの文字列を結合したものになる。少なくとも2つのパラメータがなければならないがそれより多くても良い。例えば: concat("Value is ", str(A,3,1), " inches")は、もし浮動小数点数値Aが12.34であれば、結果は"Value is 12.3 inches"という文字列になる。 file_exists(S1): S1で指定されたファイルを探す。文字列S1で名前が指定されるファイルを開くことを試みる。カレントディレクトリとLibrary_Path INIオプションあるいは+Lスイッチで指定されたすべてのディレクトリが探される。ファイルは直ちに閉じられる。成功すれば1失敗すれば0のブール値を返す。 str(A,L,P): 浮動小数点数 A を書式化した文字列に変換する。浮動小数点数値Aの書式化した文字列表現を返す。浮動小数点数パラメータLは文字列の最小の長さを指定し、最小値よりその文字列表現が短ければ左詰め形式が用いられる。もしLが正なら空白が詰められる。もしLが負なら0が詰められる。すべてにおいて書式化された文字列の最小の長さはabs(L)である。もし、その文字列を長くする必要があれば、値を表現するのに必要な長さにされる。浮動小数点数パラメータPは小数点の後ろの数字の数を指定する。もしPが負数なら、コンパイラーに依存するデフォルトの精度が用いられる。ここにいくつか例を示す: str(123.456,0,3) "123.4 str(123.456,4,3) "123.456" str(123.456,9,3) " 123.456" str(123.456,-9,3) "00123.456" str(123.456,0,2) "123.46" str(123.456,0,0) "123" str(123.456,5,0) " 123" str(123.000,7,2) " 123.00" str(123.456,0,-1) "123.456000" (プラットホーム依存) strcmp(S1,S2): 文字列S1をS2と比較する。文字列が等しければ浮動小数点数値0を返し、もしS1がASCIIで対照した順序でS2の後にくれば、正の値を返し、それ例外では負数を返す。 strlen(S1): S1の長さ。文字列S1中の文字数を整数で返す。 strlwr(S1): S1の小文字化。文字列S1中のすべての英大文字を小文字にした新しい文字列を返す。オリジナルの文字列には影響しない。例えば、strlwr("Hello There!")の結果は"hello there!"。 substr(S1,P,L): S1の部分文字列。パラメータS1の整数値Pで指定された位置を始点とする整数値Lで指定される長さの部分文字列を返す。例えばsubstr("ABCDEFGHI",4,2)は文字列"EF"に評価される。もし P+L>strlen(S1)ならエラーが発生する。 strupr(S1): S1の大文字化。文字列S1中のすべての英小文字を大文字にした新しい文字列を返す。オリジナルの文字列には影響しない。例えばstrupr("Hello There!")の結果は"HELLO THERE!"になる。 val(S1): 文字列S1を浮動小数点数に変換する。S1中のテキストで表現される浮動小数点数値を返す。例えばval("123.45")は浮動小数点数として123.45を返す。 7.2 言語命令(Language Directives※) (※訳注:Direvtiveは「指示語」、「指令」の意もあるが本翻訳では「命令」とする) POVシーン言語は、どのようにその仕事をするかをファイルパーサー(文法解析部)に教える言語命令と名づけられるいくつかの構文を持つ。これらの言語命令はシーンファイルの中のほとんどすべての場所に現れることができる-いくつかの他の構文の真ん中にさえも。それらはコマンドストリーム中の他のテキストファイルをインクルードするためや、識別子を宣言するため、条件やループした解析の定義およびシーンファイル処理におけるその他の重要な状況を制御するために使われる。 それぞれの命令はハッシュ(hash)文字#で始まる (しばしばナンバーサインあるいはポンドサインと呼ばれる)。これにキーワードが続き、オプションで他のパラメータが続く。 POV-Rayの3.0より前のバージョンでは、この#文字の使用はオプションであった。言語命令はオブジェクト、cameraあるいはlight_source文の間でのみ使うことができ、それらの文の中には現れる事ができなかった。例外は、どこにも現れることができる#includeであった。今、すべての言語命令をほとんどどこにでも使うことができるので、#文字は必須である。 続くキーワードは、言語命令を紹介する。 #break #default #statistics #case #else #switch #debug #end #version #declare #render #warning 初期のバージョンのPOV-Rayは#max_intersectionsを考慮した。そして、言語命令である#max_trace_levelはglobal_settings構文(statement)に移動した。それらの命令(directive)としての使用はまだ動作するが警告を生じ、将来はやめられるかも知れない。 7.2.1 インクルードファイル 本言語は以下の行で指定されるインクルードファイルを入力ファイル中の任意の場所で許す。 #include "filename.inc" ファイル名は任意の有効な文字列式で指定されても良いが、通常は二重引用符で囲まれたリテラル文字列である。それは2つの二重引用符文字を含めて最大40文字の長さ(あるいはあなたのコンピュータの制限)である。 インクルードファイルはその点に挿入されるものとして読み込まれる。includeの使用は実際にこのファイルの内容全体をカットし、あなたのシーンにペーストするのと同じである。 インクルードファイルはネストすることができる。最大10のネストしたインクルードファイルが可能である。ネストしないインクルードファイルには制限がない。 一般に、インクルードファイルはシーンのためのデータを持っているが、それ自身はシーンではない。 慣習としてシーンファイル名は.povで終わり、インクルードファイル名は.incで終わる。 ファイル指定において、ドライブとディレクトリを指定することは正当であるが、それはシーンファイルのさまざまなプラットホーム間での可搬性を減少するので勧められない。 特定のサブディレクトリに標準インクルードファイルを置くのは典型的である。POV-Ray はカレントディレクトリあるいはLibrary_Pathオプションで参照されるディレクトリからしかファイルを読み込めない(セクション"Library Paths"を見て下さい )。 7.2.2 宣言(Declare) 識別子は、シーンファイルをより読みやすくするためやシーンをパラメータ化し一つの宣言の変更で多くの値を変更するために宣言し、後で参照しても良い。POV-Rayがあなたのために宣言するいくつかのデフォルトの組み込み識別子がある。詳細は"Built-in Identifiers"を見て欲しい。 7.2.2.1 識別子の宣言 識別子は以下のように宣言できる。 #declare 識別子 = 項目 ここで"識別子"は40文字までの長さの識別子の名前であり、"項目"は以下のいすれかである。 浮動小数点数(float)、ベクトル(vector)、カラー(color)あるいは文字列(string)式(expressions) オブジェクト(objects) (全種類) テクスチャ(texture)、ピグメント(pigment)、法線(normal)、仕上げ(finish)あるいは ハロー(halo) カラーマップ(color_map)、ピグメントマップ(pigment_map)、傾斜マップ(slope_map)、法線マップ(normal_map) カメラ(camera)、光源(light_source) 大気(atmosphere) フォグ(fog) 虹(rainbow) 天球(sky_sphere) 変換(transform) ここにいくつかの例を示す。 #declare Rows = 5 #declare Count = Count+1 #declare Here = <1,2,3> #declare White = rgb <1,1,1> #declare Cyan = color blue 1.0 green 1.0 #declare Font_Name = "arial.ttf" #declare Ring = torus {5,1} #declare Checks = pigment { checker White, Cyan } object{ Rod scale y*5 } // "cylinder { Rod }"ではない object { Ring pigment { Checks scale 0.5 } transform Skew } 宣言(declare)はほとんどの言語命令と同じように、ファイルのどこにでも現れることができる- 他の構文の中でさえも。例えば: #declare Here=<1,2,3> #declare Count=0 // Countの初期化 union { object { Rod translate Here*Count } #declare Count=Count+1 // union内での再宣言 object { Rod translate Here*Count } #declare Count=Count+1 // union内での再宣言 object { Rod translate Here*Count } } この例で示すように、あなたは識別子を再宣言することができ、その再宣言の中で、以前に宣言された値を用いることができる。しかしながら、あなたが識別子の再宣言でそのオリジナルな型と異なる宣言を試みると警告メッセージを生ずるだろう。 宣言は制限内で互いに内側にネストしても良い。前のセクションの例で、あなたは全体の結合(union)を一つのオブジェクトとして宣言することができた。しかし、技術的な理由により、あなたは浮動小数点数(floats)、ベクトル(vectors)あるいはcolor式の宣言の内側で言語命令を使ってはならない。 7.2.3 デフォルト(Default)命令 POV-Rayは処理を開始するときにデフォルトテクスチャを作成する。あなたが、それらのデフォルトを下記に記述するように変えてもよい。あなたがtexture {... }文を指定すると、毎回POV-Rayはデフォルトテクスチャのコピーを作成する。あなたがテクスチャ構文に入るものすべてはデフォルト設定を無効にする。もしあなたが、ピグメント(pigment)、法線(normal)あるいはフィニッシュ(finish)をあるオブジェクトにtexture文無しで付けると、POV-Rayはテクスチャがすでに付けられているかどうか見るためにチェックする。もしそれがテクスチャを持っている場合、そのピグメント、法線あるいは仕上げは既存のテクスチャを修正する。もしテクスチャがまだそのオブジェクトに付けられていない場合、デフォルトのテクスチャがコピーされピグメント、法線あるいは仕上げがそのテクスチャを修正する。 あなたはデフォルトのテクスチャ(texture)、ピグメント(pigment)、法線(normal)あるいは仕上げ(finish)を以下のような言語命令#default {... }で変更しても良い: #default { texture { pigment {...} normal {...} finish {...} } } あるいはその一部分を以下のように変更しても良い: #default { pigment {..}. } これはまだデフォルトテクスチャのピグメント(pigment)を変更する。いつでもデフォルトのピグメント(pigment)、法線(normal)および仕上げ(finish)から作られたたった一つのデフォルトテクスチャがある。上の例はピグメントだけのための別々のデフォルトを作らない。特殊テクスチャタイル(special textures tiles)およびマテリアルマップ(material_map)あるいはテクスチャマップ(texture_map)をもつテクスチャをデフォルトとして使ってはならないことを注意する。 あなたはシーンを通して何度もデフォルトをあなたが望むように変えてもよい。以降の#default構文は、その時に効果のあったデフォルトから始まる。もし、あなたがオリジナルのPOV-Rayデフォルトにリセットしたければ、あなたは最初にそれらを以下のように保存しなければならない: //ファイルの先頭 #declare Original_Default = texture {} 後に、デフォルトが変更された後、それを... #default {texture {Original_Default}} で元に戻しても良い。 あなたがオブジェクトにテクスチャを指定しなければ、シーンにオブジェクトが現れるとき、デフォルトテクスチャが付加される。それはオブジェクトが宣言される時には付加されない。例えば: #declare My_Object = sphere{ <0,0,0>, 1 } // デフォルトテクスチャは適用されない object { My_Object } // ここでテクスチャが加えられる あなたは次のように、デフォルトテクスチャに空のテクスチャ構文を使うことによって付け加えるのを強制することもできる： #declare My_Thing = sphere { <0,0,0>, 1 texture {} } // デフォルトテクスチャが適用される すべての項目に対するオリジナルのPOV-Rayデフォルトはこのドキュメンテーションを通して適当なセクションで与えられる。 7.2.4 バージョン(Version)命令 POV-Ray 3.0のために多くの言語変更がなされたが、バージョン2.0の構文と大部分のバージョン1.0の構文のすべてはまだ働く。可能であるときは常に、我々は後ろ向きの互換性を維持しようとする。1.0のシーンファイルとの互換性のないもので2.0の中で導入された一つの機能は、浮動小数点数式の解析である。+MV 1.0 コマンドラインスイッチあるいはVersion =1.0 INIオプションのセットは多くの警告メッセージと同様に、数式の解析をoffにし、ほとんどすべての1.0ファイルはまだうまく働く。2.0と3.0の間の変更はそれほど大規模でない。Version =2.0 の設定はいくつかの警告メッセージを除去するために必要なだけである。当然、このオプションのデフォルト設定はVersion=3.0である。 #version 言語命令はシーンファイルの中でモードを変更するために使われる。このスイッチあるいはINIオプションは初期設定(initial setting)のみに影響する。 組み込みversion識別子と共に、#version命令はこの互換性設定の以前の値の保存と、元に戻すことを可能にする。例えばmystuff.incがversion 1.0 形式としよう。ファイルの先頭にあなたは以下の行を置ける: #declare Temp_Vers = version // 以前の値を保存 #version 1.0 // 1.0 モードに変更 ... // バージョン1.0の物は、ここに行く...... #version Temp_Vers // 以前の値を元に戻す 以前のバージョンのPOV-Rayは、versionの変更を、オブジェクトあるいは宣言の内側では許さなかったが、この制限はPOV-Ray 3.0で取り除かれた。 将来のバージョンのPOV-Rayは#version命令を用いても、完全な後ろ向きの互換性を維持し続けないかもしれない。我々は、あなたが3.0の構文をできるだけ多く、段階的に導入するのを強く奨励する。 7.2.5 条件付き命令(Conditional Directives) POV-Ray 3.0はあなたのシーンファイルのいろいろなセクションの条件付き構文解析をインプリメントするために様々な新しい言語命令を許す。これは特にアニメーションのための運動を記述することに役立つし、また他の利用法も持つ。また、#whileループ命令が、利用可能である。条件付き命令は200レベルの深さまでネスト可能である。 (訳注:条件付き命令のサンプルはディレクトリpov3demo\otherにある。) 7.2.5.1 IF ELSE 命令 最も単純な条件付き命令は伝統的な#if命令である。それは以下の形式をとる... #if (条件) // このセクションは // 条件がtrueの場合構文解析される #else // このセクションは // 条件がfalseの場合構文解析される #end // 条件部の終了 ここで (条件)は浮動小数点数式でブール値として評価される。値 0.0 は偽(false)であり、ゼロ以外の値はすべて真(true)である。きわめて小さい1e-10ぐらいの値は丸め誤差のためゼロとみなされる。条件を囲む括弧は必要である。#else命令はオプションである。#end 命令は必要である。 7.2.5.2 IFDEF 命令 #ifdef命令は#if命令と類似しているが、ある識別子が既に宣言されているかを判断するために用いられる。#ifdef命令の後ろにブール式の代わりに括弧で囲まれた単独の識別子を置く。例えば: #ifdef (User_Thing) // このセクションは識別子 // "User_Thing"が既に宣言されていれば // 構文解析される object{User_Thing} // 識別子を呼び出す #else // このセクションは識別子 // "User_Thing"がまだ宣言されていなければ // 構文解析される box{<0,0,0>,<1,1,1>} // デフォルトを使う #end // 条件部分の終了 7.2.5.3 IFNDEF 命令 #ifndef命令は#ifdef命令と類似しているが、それは与えられた識別子がまだ宣言されていないかどうかを判断する。例えば: #ifndef (User_Thing) // このセクションは識別子 // "User_Thing"がまだ宣言されていなければ // 構文解析される box{<0,0,0>,<1,1,1>} // デフォルトを使う #else // このセクションは識別子 // "User_Thing"が既に宣言されていれば // 構文解析される object{User_Thing} // 識別子を呼び出す #end // 条件部分の終了 7.2.5.4 SWITCH CASE および RANGE 命令 (訳注:SWITCH文のサンプルはpov3demo\other\switch1〜4.pov参照 最も強力な条件式は#switch命令である。その構文は以下のようになる... #switch (値) #case (TEST_1) // もし 値=TEST_1ならこのセクションが構文解析される #break //最初の case の終了 #case (TEST_2) // もし 値=TEST_2ならこのセクションが構文解析される #break //2番目のcase の終了 #range (LOW_1,HIGH_1) // もし(値>=LOW_1)&(値<=HIGH_1)ならこのセクションが構文解析される #break //3番目のcase の終了 #range (LOW_2,HIGH_2) // もし(値>=LOW_2)&(値<=HIGH_2)ならこのセクションが構文解析される #break //4番目のcaseの終了 #else // このセクションは他のcaseあるいはrangeがtrueならば // 構文解析される。 #end // 条件部分の終了 #switch命令に続く浮動小数点数式"値"は評価され#case あるいは #range 命令にある値と比較される。#caseを使う場合、括弧に囲まれた浮動小数点数式TEST_1が使われる。それは"値"と比較される。通常通りPOV-Rayでは、それらの差が1e-10より小さければ、浮動小数点数比較は等しいとみなされる。その値が等しければ、構文解析は通常通り #break、#elseあるいは#end命令にたどり着くまで続けられる。もし比較が失敗すれば、別の#caseあるいは#rangeが見つかるまでPOV-Rayはスキップする。 もし、あなたが#range命令を使う場合、それに括弧で囲まれコンマで区切られた2つの浮動小数点数式LOW_1とHIGH_1が続く。もし、switchの"値"が指定された範囲にあれば、構文解析は#break、#elseあるいは#end命令にたどり着くまで続けられる。もし、"値"がその範囲に無ければ比較は失敗し、POV-Rayは別の#caseあるいは#rangeが見つかるまでスキップする。 いずれの#caseも#rangeも成功しなければ、#elseセクションが解析される。#else命令は、選択可能である。もし、 #elseが指定されなかったり、どのマッチも成功しなければ構文解析は、#end命令の後再開する。 あなたが望む任意の順位で、任意の数の#caseあるいは#range命令があっても良い。一つのセグメントがtrueに評価され、#breakが指定されていなければ、構文解析は次の#case あるいは#rangeに落ち、通して#break、#elseあるいは#endまで続けられる。成功したセクションを構文解析している間に#breakに突き当たると、以降のセクションの条件が満足していたとしても、残りのセクションの解析をせずに#endまでの即時ジャンプが引き起こされる。 7.2.5.5 WHILE 命令 #while命令は、パターンの中に複数のオブジェクトを配置するのを簡単にしたり、他の用途に用いるための繰り返し(ルーピング)機能である。#while命令には浮動小数点数式が続き、それはブール値として評価される。値0.0はfalseで他のゼロでない値はtrueである。丸め誤差により1e-10ぐらいのきわめて小さい値はゼロとみなされる。式を囲む括弧は必要である。もし、条件がtrueであれば、構文解析は#end命令にたどり着くまで通常通り続けられる。その終わりにはPOV-Rayは#while命令にループする。そして条件は再評価される。条件が失敗するまで、繰り返しは続く。それが失敗すると、構文解析は#end命令の後から続けられる。例えば: #declare Count=0 #while (Count < 5) object{MyObject translate x*3*Count} #declare Count=Count+1 #end この例では、MyObjectの5つのコピーをx方向に3単位列間隔をあけて配置する。 7.2.6 ユーザーメッセージ命令 条件付き命令、およびループ命令に加えて、POV-Ray言語はより実際のプログラミング言語のようなポテンシャル(潜在性)を持つ。これは、ループや条件式をデバッグしようとしているとき、何が進行しているかを見るためのいくつかの方法が必要だろうということを意味する。この要求を満たすために、我々は画面にテキストメッセージを出力する能力を付け加えた。あなたがそれが必要だと思うなら致命的なエラーを生成することもでき、5つの異なるテキストストリームの選択を行うことができる。この方法による文字列出力のために、制限付きのフォーマッティングが利用できる。 (訳注:サンプルはpov3demo\other\message.pov参照) 7.2.6.1 テキストメッセージストリーム テキストメッセージの構文は以下のいずれかである: #debug 文字列 #error 文字列 #error 文字列 #render 文字列 #statistics 文字列 #warning 文字列 ここで"文字列"は文字列識別子と文字列を返す関数を含む任意の有効なテキスト文字列である。例えば: #switch (clock*360) #range (0,180) #render "Clock in 0 to 180 range\n" #break #range (180,360) #render "Clock in 180 to 360 range\n" #break #else #warning "Clock outside expected range\n" #warning concat("Value is:",str(clock*360,5,0),"\n") #end POV-Rayは7つの別々のテキストストリームを出力に用いる。いくつかのバージョンでは個々のストリームを特定の色で表示される。これらのストリームからのテキストはそれが適当な場合は常に表示されるので、しばしばテキストが混在する。ストリームの区別はストリームのいくつかをoffに切り替えたり、ストリームのいくつかをテキストファイルに出力する場合だけに必要である。いくつかのシステムでは、個々のスクロールバッファで、別々にストリームに目を通すことが可能である。ストリームのテキストファイルへのリダイレクション(出力先の変更)についての詳細は"コンソールテキスト出力"を見て下さい ここでPOV-Rayがそれぞれのストリームをどのように使うかを説明する。あなたはこれらを#errorストリームの使用がテキストを表示した後、致命的エラーを引き起こすこと注意するのを除き、あなたの望むいろいろな目的で使うことができる。 デバッグ(DEBUG): このストリームはデバッギング・メッセージを表示する。これは主として開発者のために設計された。しかし、これと他のストリームはシーンファイルの中からのメッセージを表示するためにもユーザーに使われる。 フェイタル(FATAL): このストリームは致命的エラーのメッセージを表示する。このメッセージを表示した後、POV-Rayは終了する。もし、エラーがシーン解析エラーの場合、このエラーの原因となったシーンテキストの2、3行が表示される。 レンダー(RENDER): このストリームはあなたがシーンをレンダリングするためにどんなオプションを指定したかについての情報を表示する。これはシーン名、解像度、アニメーションセッティング、アンチエイリアシングおよび他のすべての主なオプションのフィードバックを含む。 統計(STATISTICS): このストリームは一つのフレームがレンダリングされた後の統計を表示する。これはレイトレースされた数、処理にかかった時間、などの情報を含む。 警告(WARNING): このストリームはシーンファイルの解析中の警告(warning)メッセージをあるいは他の警告メッセージを表示する。警告にかかわらず、POV-Rayはシーンをレンダリングし続けることができる。 7.2.6.2 テキストフォーマットティング(Text Formatting) あなたのテキストに印刷不可能な制御文字を含めるためにいくつかのエスケープシーケンスが利用できる。これらのシーケンスはC言語の文字列リテラルで用いられるものと類似している。これらの制御文字はテキストメッセージ命令にだけ適用されることを注意する。これらはテキストオブジェクトやファイル名のようなPOV-Rayの他の文字列の使用では実行されない。あなたの使っているプラットホームに依存し、コンソール出力に対してはこれらは完全にはサポートされないかもしれない。しかし、あなたが、ストリームをファイルにリダイレクトする場合、テキストファイルにそれらは現れる。シーケンスは: "\a" ベルあるいはアラーム、0x07 "\b" バックスペース, 0x08 "\f" フォームフィード(改ページ)、0x0C "\n" ニューライン(ラインフィード) 0x0A "\r" キャリッジリターン 0x0D "\t" 水平タブ 0x09 "\v" 垂直タブ 0x0B "\0" ヌル(Null) 0x00 "\\" バックスラッシュ 0x5C "\'" シングルクォート(Single quote) 0x27 "\"" ダブルクォート(Double quote) 0x22 例えば: #debug "This is one line.\nBut this is another" ( #debug "これは一つの行\nでもこれは別の行" ) 7.3 POV-Rayの座標系(Coordinate System) オブジェクト、ライトおよびカメラは、典型的な3D座標系を使って配置される。POV-Rayの普通の座標系は、上を指す正のy-軸、右側を指す正のx-軸および画面を指す正のz-軸を有する。「POV-Rayの座標系を理解する」のセクションの中の図で示ように、軸の負の値は他の方向を示す。 その座標系内の位置は、通常、3成分ベクトルによって指定される。3つの値は、それぞれx、yおよびz方向に対応する。例えば、ベクトル<1,2,3>は、世界の中心<0,0,0>から、1単位右、2単位上で、3単位前の点を意味する。 けれどもベクトルは必ずしも点でない。それらはまた、要素をある大きさで作るためや、平行移動や回転、あるいはオブジェクトに適用されたテクスチャパターンの修正するための量として参照することができる。 サポートされる変換(transformations)は回転(rotate)、拡大縮小(scale)および平行移動(translate)である。それらはオブジェクトやテクスチャをターンさせたり、サイズを決めたり、平行移動したりするために使われる。変換マトリックスは直接複雑な変換を指定するためにも用いられる。 7.3.1 変換(Transformations) サポートされる変換は回転(rotate)、拡大縮小(scale)および平行移動(translate)である。それらは、オブジェクトやテクスチャを回転させたり、ある大きさに作ったり、平行移動したりするために使われる。 rotate <ベクトル> scale <ベクトル> translate <ベクトル> 7.3.1.1 平行移動(Translate) オブジェクトやテクスチャパタンは平行移動(translate)パラメータを加えることにより平行移動できる。それは、ベクトル式が続く、キーワードtranslateから成る。ベクトルの項は、それぞれx、yおよびz方向に動かすための単位数を指定する。平行移動(Translate)はエレメントをその現在の位置に相対的に平行移動する。例えば sphere { <10, 10, 10>, 1 pigment { Green } translate <-5, 2, 1> } は、この球を<10,10,10>から<5,12,11>に平行移動する。これは、それを絶対的な位置<-5,2,1>に平行移動するのではない。ゼロによる平行移動はエレメントのその座標をそのままにしておく。例えば: sphere { <10, 10, 10>, 1 pigment { Green } translate 3*x // <3,0,0>に評価されるので3単位 // x方向に。y および z方向にはしない } 7.3.1.2 拡大縮小(Scale:スケール) あなたは、拡大縮小(scale)パラメータを付け加えることによってオブジェクトやテクスチャパターンのサイズを変えてもよい。それは、ベクトル式が続くキーワードscaleから成る。ベクトルの3つの項は、それぞれx、yおよびz方向に拡大縮小する量を指定する。 拡大縮小は要素を引き伸ばしたりつぶすために使われる。1より小さい値はそれをつぶすために使われ、1より大きい値はその軸上で要素を引き伸ばす。拡大縮小は、現在の要素サイズに相対的である。あるエレメントが以前に拡大縮小(scale)を用いてサイズ変更されている場合、拡大縮小は新しいサイズに相対的である。複数の拡大縮小値を使っても良い。 例えば sphere { <0,0,0>, 1 scale <2,1,0.5> } は、球をx-方向に沿って元のサイズの2倍に、y-方向はそのままに、そしてz-方向は元のサイズの半分に引き延ばしたり潰したりして楕円体の形にするだろう。 もし、1つの浮動小数点数式だけが指定された場合、それは項がすべて同じ3成分ベクトルにプロモートされる。このように、その事物はすべての方向に同じ量で均一に拡大縮小される。例えば: object { MyObject scale 5 // <5,5,5>に評価されるのですべての方向に // 5倍に拡大される。 } 7.3.1.3 回転(Rotate) あなたはオブジェクトやテクスチャパターンの方向を回転(rotate)パラメーターを加えることにより変更することができる。それは、キーワードrotateに続くベクトル式からなる。ベクトルの3成分はそれぞれx-, y- および z-軸に関する回転量を度数で指定する。 回転の順序が問題となることを注意する。回転はx-軸に関して最初に、次にy-軸、次にz-軸に関して起こる。もし、あなたが複数の回転構文を用いる時に、それがあなたの求める物かどうかはっきりしない場合、あなたは正しい回転を得るために、たった一つの軸について回転させるべきである。 rotate <0, 30, 0> // 30 度Y軸まわりに回転し、 rotate <-20, 0, 0> // -20 度X軸まわり回転し、 rotate <0, 0, 10> // 10 度Z軸まわりに回転。 回転(Rotation)は軸に相対的に実行される。つまり、もしオブジェクトが回転軸からいくらかの距離がある場合、まるで見えない糸でぐるりと回るように、その軸に関して軌道に沿って回る。 回転方向を研究するために、あなたはセクション「POV-Rayの座標系を理解する」で説明された、有名なコンピュータグラフィックスエアロビクス運動を実行しなければならない。 7.3.1.4 Matrix(マトリックス)キーワード matrixキーワードはオブジェクトやテクスチャに使うための変換マトリックスを明示的に指定するために使うことができる。その構文は: matrix < m00, m01, m02, m10, m11, m12, m20, m21, m22, m30, m31, m32 > ここで m00 から m32 は浮動小数点数式で、4番目列が暗黙的に<0,0,0,1>で指定される4*4マトリックスの要素を指定する。一点P、P=,、はQ、Q=に qx = M00 * px + M10 * py + M20 * pz + M30 qy = M01 * px + M11 * py + M21 * pz + M31 qz = M02 * px + M12 * py + M22 * pz + M32 により変換される。 通常あなたは、matrixキーワードを使わないだろう。なぜなら、それは変換コマンドに比べて記述性に欠け、視覚化するのが難しいからである。けれどもマトリックスコマンドには一つの側面(intersecting aspect)がある。それはせん断(shearing)のようなより一般的な変換を可能にする。以下のマトリックスはオブジェクトにy-軸に沿ったせん断変形を引き起こす。 object { MyObject matrix < 1, 1, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0 > } (訳注:matrixを用いたせん断変形のサンプルはpov3demo\other\matrix.pov,shear1〜3.pov参照) 7.3.2 変換の順序 回転が常に軸に相対的であり、また拡大縮小が原点に相対的であるから、あなたは一般に原点にオブジェクトを作成し、それから最初に拡大縮小と回転をしたいだろう。それから、それを正しい位置に平行移動しても良い。慎重にオブジェクトの位置を決め、それからそれの回転を決めるのはよくある間違いである。なぜならオブジェクトの回転はその軸に関する旋回(orbit)を引き起こし、旋回しすぎてカメラの視野から外れるほどオブジェクトの位置が変わってしまうかも知れない! 同様に平行移動(translation)の後の拡大縮小もオブジェクトを予想外に移動する。もしあなたが平行移動の後拡大縮小すると、その拡大縮小は移動量に掛けられる。例えば translate <5, 6, 7> scale 4 は<5,6,7>の代わりに<20,24,28>へ移動する。変換においてはあなたの目的にあった正しい順序をを得るように注意しなさい。 7.3.3 変換(Transform)識別子 いくつかの変換をひとまとめに結合して複数の場所でそれらを適用することがしばしば役に立つ。この目的のために変換識別子を使うことができる。変換識別子は以下のように宣言される: #declare 識別子 = transform { 変換... } ここで"識別子"は宣言する識別子で"変換"は1つあるいはそれ以上の変換(translate)、回転(rotate)、拡大縮小(scale)あるいはマトリックス(matrix)定義か既に宣言されている変換識別子である。ここに示すように、変換識別子は括弧無しのtransformキーワードによって呼び出される: object { MyObject // MyObjectのコピーを得る transform MyTrans // 変換を適用する translate -x*5 // それからそれを5単位左に平行移動する } object { MyObject // MyObjectの別のコピーを得る transform MyTrans // 同じ変換を適用する translate -x*5 // それからこれを5単位右に平行移動する } たくさんのコンポーネントを持つきわめて複雑なCSGオブジェクトでは、個々の平行移動(translate)、回転(rotate)、拡大縮小(scale)あるいはマトリックス(matrix)定義よりもむしろ宣言された変換を適用することのほうが構文解析をスピードアップする。変換はたった一度だけそれぞれのコンポーネントに付加される(attached)。個々の平行移動、回転、拡大縮小あるいはマトリックス定義をそれぞれ適用することは時間がかかる。これは構文解析に影響するだけで、レンダリングはいずれの方法でも同じに働く。 7.3.4 テクスチャとオブジェクトの変換 あるオブジェクトが変換される場合、そのときオブジェクトに付加されているすべてのテクスチャは同様に変換される。このことは、あなたがオブジェクトの中でテクスチャ(texture)の前に、平行移動(translate)、回転(rotate)、拡大縮小(scale)あるいはマトリックス(matrix)を持つ場合、そのテクスチャは変換されないことを意味する。その変換がtextureの後であれば、テクスチャはそのオブジェクトと共に変換される。その変換がtexture {... }構文の中にあれば、そのテクスチャだけが影響を受ける。形状はそのままである。例えば: sphere { 0, 1 texture { Jade } // TEXTURES.INCからのテクスチャ識別子 scale 3 // このscaleは形状とテクスチャの // 両方に影響する } sphere { 0, 1 scale 3 // このscaleは形状だけに影響する texture { Jade } } sphere { 0, 1 texture { Jade scale 3 // このscaleはテクスチャだけに影響する } } また、変換を独立にピグメントパターンと表面法線パターンに適用することもできる。法線パターンの拡大縮小では幅と間隔だけに影響を及ぼす点に注意しなさい。バンプ(凹凸)の外見上の高さ、あるいは深さには影響しない。例えば: box { <0, 0, 0>, <1, 1, 1> texture { pigment { checker Red, White scale 0.25 // これはカラーパターンだけに影響する } normal { bumps 0.3 // これはbumps(凹凸)の見かけの高さを指定する scale 0.2 // 直径と凹凸間の間隔を縮小するが // 高さは縮小しない。カラーパターンには // 影響しない。 } rotate y*45 // これはテクスチャ全体に影響するが } // オブジェクトには影響しない。 } 7.4 カメラ(Camera) カメラ(camera)定義は、シーンを眺めるカメラの位置、投影タイプおよび特性を記述する。その構文は以下の通りである。 camera { [ perspective | orthographic | fisheye | ultra_wide_angle | omnimax | panoramic | cylinder 浮動小数点数 ] location <ベクトル> look_at <ベクトル> right <ベクトル> up <ベクトル> direction <ベクトル> sky <ベクトル> right <ベクトル> angle 浮動小数点数 blur_samples 浮動小数点数 aperture 浮動小数点数 focal_point <ベクトル> normal { 法線 } } 投影タイプによっていくつかのパラメータが必要である。いくつかは選択可能であり、そしていくつかは使われない。投影タイプが与えられなければ、透視投影(perspective)のカメラ（ピンホールカメラ:針穴写真機）が使われるだろう。カメラが指定されなければデフォルトのカメラが使われる。 すべてのカメラはカメラの位置と方向づけを決定するために投影タイプに関係なく、location、look_at、right、up、directionおよびskyキーワードを使う。それらの意味は用いられる投影タイプによって相違する。カメラ配置のより詳細な説明が以下に続く。 (訳注:さまざまなカメラのサンプルはpov3demo\cameraディレクトリにある。 camera1a.pov:透視投影カメラ camera1b.pov:正射投影カメラ camera1c.pov:魚眼カメラ camera1d.pov:超魚眼カメラ camera1e.pov:オムニマックスカメラ camera1f.pov:超広角カメラ camera3a.pov:タイプ１円筒投影カメラ camera3b.pov:タイプ２円筒投影カメラ camera3c.pov:タイプ３円筒投影カメラ camera3d.pov:タイプ４円筒投影カメラ focalb1.pov:焦点ぼけ ) 7.4.1 投影のタイプ(Type of Projection) 続くリストでは、カメラで使うことができるそれぞれの投影タイプを説明する。最も普通のタイプは、透視投影(perspective)と正射投影(orthographic)である。 透視投影(Perspective projection:透視射影ともいう)：この投影は、古典的なピンホールカメラを表現する。(水平な)視角(viewing angle)は方向ベクトル(direction vector)の長さと右方向ベクトル(right vector)の長さの比、あるいはむしろ好まれる方法であるオプションのキーワードangleで指定される。視角は0度より大きく、180度未満でなければならない。透視投影カメラの幾何学については以下の図を見て下さい。 図 透視投影カメラ(The perspective camera)。 正射投影(Orthographic projection:正射影、直投影ともいう)：この投影は、シーンのイメージを作成するために平行なカメラ光線を使う。イメージのサイズは、右方向(right)および上方向(up)ベクトルの長さによって決定される。あなたが透視投影のカメラで、すべての他のパラメータの後ろにorthographicキーワードを付け加えると、あなたは同じイメージ領域で正射投影の眺めを得るだろう。すなわち、イメージのサイズは同じものである。この場合、あなたは右方向(right)および上方向(up)ベクトルの長さを指定する必要はない。それらは自動的に計算される。あなたは、透視投影(perspective)から正射投影(orthographic)の視野に切り換えた場合、シーンの見える部分は変わるということを知っていなければならない。正射投影のカメラが使われる場合、すべての重要なオブジェクトが参照点(look_at)位置の近くにある限り、それらはまだ見えるだろう。近くのオブジェクトは視野の中に見えるままでいるが、より遠くのオブジェクトは視野から消える。 魚眼(Fisheye:フィッシュアイ)投影：これは、球形の投影である。視角はangleキーワードによって指定される。180度のangleは「通常の」魚眼を作成し、360度のangleは超魚眼(見える物を総て見る"I-see-everything-view")を作成する。あなたがこの投影を使うならば、あなたは円形のイメージを得るはずである。そうでない場合、すなわちあなたが楕円のイメージを得る場合、あなたは「アスペクト比(Aspect Ratio)」を読まなければならない。 超広角投影(Ultra wide angle projection):この投影はいくぶん魚眼に似ている、しかし、それは円の代わりにイメージを長方形に映す。視角は、angleキーワードを使って指定することができる。 オムニマックス投影(Omnimax projection):オムニマックス投影は垂直方向の視角を減少した180度程度の魚眼である。実際は、この投影はドームのようなオムニマックス劇場の中で見る映画を作るために使われる。イメージはいくぶん楕円に見るだろう。angleキーワードはこの投影では使われない。 パノラマ投影(Panoramic projection): この投影は「等矩形円筒投影(clyndrical equirectangular)」と名づけられる。視角が180度に接近した場合の透視投影の変質(degenerateion)問題を克服する。我慢できる程度の横方向に伸びるゆがみで180度以上の視角を用いるために円筒形の投影を使う。angleキーワードが視角を決めるために用いられる。 円筒投影(Cylindrical projection):この投影を用いるとシーンは円筒上に投影される。円筒の向きと視点の位置に基づいて、円筒投影の4つの異なるタイプがある。視角と上方向(up)および右方向(right)ベクトルの長さはカメラと見えるイメージの寸法を決定する。 (訳注:このあたりテキストが乱れていたので整理した) そのタイプは: 　1 垂直円筒、固定視点 2 水平円筒、固定視点 3 垂直円筒、視点が円筒の軸に沿って移動する 4 水平円筒、視点が円筒の軸に沿って移動する 透視投影カメラが使われた場合、angleキーワードはdirectionキーワードで指定された視角を無効にする(あるいはその逆)。angleが使われるたびに、方向ベクトルの長さは、新しい視角に合わせるために調節される。 透視投影に対する場合を除いて視角に対する制限はない。あなたが360度より大きい視角を選ぶならば、あなたは繰り返されたシーン（反復が起こる方法はカメラに依存する）のイメージを見るだろう。これは特殊な効果に役立つかもしれない。 あなたはビスタバッファ(vista buffer)が透視投影(perspective)および正射投影(orthographic)カメラでのみ使用できる点に注意しなければならない。 7.4.2 焦点ぼけ(Focal Blur) 各ピクセル内のジッタされた(jittered)点からたくさんのサンプル光線に投げかけて、答えを平均することによって焦点の被写界深度(depth-of-field)をシミュレートする。 aperture(開口)設定は、シャープ(sharpness)な領域の深さを決定する。狭いapertureはシャープな領域の広がりを与え、大きいapertureは、多くのぼけ(blurring)を与える。この作用は実際のカメラの作用のようであるが、apertureの設定はまったく任意であり、カメラのf値の区切り(f-stops)には関係しない点を注意する. シャープな領域の中心はfocal_point(焦点)ベクトルである(デフォルトのfocal_pointは<0,0,0>である)。 blur_samples値は、それぞれのピクセルために使う光線の最大数を制御する。さらなる光線の発射が意味のある結果にならないという適当な信頼度に到達した場合、光線の発射を停止する適合(adaptive)メカニズムによって幾分制御できるけれども、多くの光線はよりスムーズな外観を与えるがより遅くなる。 confidence(信頼度)およびvariance(変動)キーワードは適合関数を制御する。confidence値はサンプルが十分真の色に近いと判断する時期を決めるために用いる。variance値は、今までに採られたサンプルの変動に関して、受け入れ可能な許容限界量を指定する。言い換えると、光線発射プロセスは評価された色値が実際の色値に十分に近づいたら(信頼確率によって制御され)終了する。 confidenceは確率であるからその値は0から1の範囲でなければならない(デフォルトは0.9、つまり90%)。varianceに対する値は最も小さい表示可能な色の差の範囲でなければならない(デフォルトは1/128)。 より大きいconfidence値は、より多くのサンプル、より遅いトレースとより良いイメージに導くだろう。同じことが、より小さい変動しきい値(variance thresholds)にあてはまる。 デフォルトでは焦点ぼけは用いられない、つまりデフォルトのapertureは0で、デフォルトのサンプル数も0である。 7.4.3 カメラぶれ(Camera Ray Perturbation:カメラ光線の動揺) オプションのキーワードnormalを、法線パターンをカメラに割り当てるために使ってもよい。すべてのカメラ光線は、このパターンを使ってかき乱されるだろう。これはあなたに特殊な効果を作成させる。例としてアニメーションにされたシーンcamera2.povを見なさい。 7.4.4 カメラを置く 以下のセクションにおいて、カメラの配置がさらに詳しく説明されるだろう。 7.4.4.1 位置(Location)および参照点(Look_At) 多くの状況下においてcamera構文の中であなたがカメラを置くために必要とするすべては、ただ2つのベクトルだけである：それは位置(location)と参照点(look_at)である。例えば: camera { location <3,5,-10> look_at <0,2,1> } 位置(location)は単純にカメラのx, y, z座標である。カメラはレイトレーシング空間の任意の場所に置ける。デフォルトの位置(location)は<0, 0, 0>である。参照点(look_at)ベクトルはカメラが指定したx, y, z 座標を見ているようになるまでカメラを左右に回転し(pan)、傾ける(tilt)ようにPOV-Rayに指示する。デフォルトで、カメラはその置かれた位置から1単位z-方向の点を見る。 ほとんど常に、参照点(look_at)の定義は、camera構文の中の最後の項目でなければならない。他のカメラ項目が参照点(look_at)ベクトルの後で置かれた場合、カメラは指定された点を見続けないかもしれない。 7.4.4.2 天空(Sky)ベクトル 通常、POV-Rayは参照(look_at)点の線上になるまでy軸に関して左右に回転し、それから正確な点に合うまで真っ直ぐ上下に傾ける。しかしながら、あなたはバンクターン(banked turn)をしている飛行機のように、カメラを横に傾斜したいかも知れない。あなたは天空(sky)ベクトルを用いてカメラのこの傾きを変更することができる。例えば: camera { location <3,5,-10> sky <1,1,0> look_at <0,2,1> } これは、カメラのてっぺんが天空(sky)ベクトルと一致するまで、カメラをロール(roll)するようにPOV-Rayに教える。天空ベクトルはカメラのてっぺんから(天空を)指しているアンテナであると想像すればよい。その時天空(sky)ベクトルは左右への回転軸として、また天空ベクトルの線上に上下に傾斜するために使われる。要するにあなたは空が真上の方向ではないと仮定するようにPOV-Rayに教えている。天空(sky)ベクトルは参照点(look_at)ベクトル以前に現れなければならないことを注意して下さい。 天空(sky)ベクトルはそれ自身では何もしない。参照点(look_at)ベクトルがカメラを回す方法を修正するだけである。 7.4.4.3 方向(Direction)ベクトル 方向ベクトル(direction vector)は参照点(look_at)あるいは回転(rotate)ベクトルにより動く前のカメラが指す最初の方向をPOV-Rayに教える(デフォルトはdirection <0, 0, 1>である)。これはまた、いくつかの投影タイプで（水平な）視界を制御することに使われることがある。けれどもそれは、より使用が簡単なangleキーワードを用いて行うべきである。 もしあなたが超広角、パノラマあるいは円筒状の投影を用いるならば、奇妙な結果を避けるために単位長さの方向ベクトルを用いるべきである。 方向ベクトルの長さは以下の投影タイプが使われる場合は問題ない:正射投影(orthographic)、魚眼(fisheye)あるいはオムニマックス(omnimax)。 7.4.4.4 角度(Angle) angleキーワードは用いられているカメラの(水平の)視角(viewing angle)を度で指定する。透視投影カメラに対しては視角を決定するために方向ベクトルを使うことが可能であるけれども、このangleキーワードを使う方がより簡単である。 一つの方法から他の方法に変換するための必要な計算が以下に述べられる。これらの計算はangleキーワードに出会ったときは常に方向ベクトルの長さを決定するために用いられる。 視角は方向ベクトルの長さに、あるいは逆に、この式を用いて変換される。視角は以下の式で与えられる angle = 2 * arctan(0.5 * right_length / direction_length) ここでright_lengthおよびdirection_lengthはそれぞれ右方向(right)および方向ベクトルの長さであり、arctanは逆正接関数である。 これにより、方向ベクトルの長さは与えられた視角(angle)と右方向(right)ベクトルから計算できる。 direction_length = 0.5 * right_length / tan (0.5 * angle ) (訳注:この部分はオリジナルのテキストに混乱があるので適当に整理した) 7.4.4.5 上方向(Up)および右方向(Right)ベクトル 上方向(up)および右方向(right)ベクトルの方向は(方向ベクトルの方向と共に)シーンの中のカメラの方向を決める。それらは、暗黙のうちにそれらのデフォルト値 right 4/3*x up y あるいは参照点(look_at)パラメータ(locationとの組み合わせで)でセットされる。明示的に指定された右方向(right)および上方向(up)ベクトルの方向はこれ以降に続く参照点(look_at)パラメータで無効にされる。 いくらかのカメラタイプではこれらのベクトルの長さを無視するけれども、他のものはカメラ設定に関する大切な情報を引用するためにそれを使う。以下に続くリストは、それぞれのカメラタイプに対する右方向(right)および上方向(up)ベクトルの意味を説明する。方向ベクトルは常にカメラの方向付けを記述するために使われるので、再び説明しない。 透視投影:上方向(up)および右方向(right)ベクトルの長さは、ビューイングウィンドウのサイズとセクション「アスペクト比」で詳細に説明されるアスペクト比を設定するのに使われる。視野(field of view)は方向ベクトルの長さ(暗黙的にangleキーワードで設定されるか、明示的にdirectionキーワードで設定される)と、右方向(right)および上方向(up)ベクトルの長さに依存するため、あなたは求める結果を得るためにそれらを慎重に選択しなければならない。 正射投影: 右方向(right)および上方向(up)ベクトルの長さは、正射投影カメラでは使われない方向ベクトルの長さに関係なく、ビューイングウィンドウのサイズをセットする。再び、長さの関係は、アスペクト比をセットするために使われる。 魚眼投影:右方向(right)および上方向(up)ベクトルの長さは、アスペクト比をセットするために使われる。 超広角投影:上方向(up)および右方向(right)ベクトルは透視投影カメラと同様に働く。 オムニマックス投影:オムニマックス投影は垂直方向の視角を減少した180度程度の魚眼である。実際は、この投影は、ドームのような、オムニマックス劇場の中で見る映画を作るために使われる。イメージは、いくぶん楕円に見るだろう。angleキーワードは、この投影では使われない。 パノラマ投影:上方向(up)および右方向(right)ベクトルは透視投影カメラと同様に働く。 円筒投影: 円筒タイプ1と3では円筒の軸は上方向(up)ベクトルに沿って横たわる、そして、幅は右方向(right)ベクトルの長さによって決められる。あるいは、それはangleベクトルで無効にされかもしれない。タイプ3において、上方向(up)ベクトルはイメージが何単位の高さかを決める。例えば、もしあなたがup 4*y を原点でカメラに付加すると、y=2からy=-2までの点だけが見える。すべての視線光線(viewing rays)はy-軸に垂直である。タイプ2および4に対して、円筒は右方向(right)ベクトルに沿って横たわる。タイプ4に対する視線光線は右方向(right)ベクトルに垂直である。 上方向(up)、右方向(right)および方向ベクトルは常に互いに垂直でなければならない。そうでないとイメージはゆがめられるであろう。そうでない場合は、警告メッセージが出力されるだろう。ビスタバッファは垂直でないカメラベクトルに対しては働かないであろう。 7.4.4.5.1 アスペクト比 右方向(right) および 上方向(up) ベクトルは一緒に結果のイメージのアスペクト比(高さの幅に対する比)を定義する。デフォルト値 up <0, 1, 0> および right<1.33, 0, 0>の結果のアスペクト比は4 対 3である。これは代表的なコンピュータモニタのアスペクト比である。あなたが高いやせっぽちのイメージか短い広いパノラマイメージが欲しいならば、あなたは上方向(up)および右方向(right)ベクトルを適当な割合に調節しなければならない。 ほとんどのコンピュータビデオモードとグラフィックプリンタは完全に正方形のピクセルを持つ。例えば、マッキントッシュのディスプレイとIBM SVGA モードの640x480、800x600および1024x768はすべて正方形のピクセルを使う。もしあなたの意図する表示方法が正方形のピクセルを使い、高さと幅を+W および +Hスイッチで指定した場合、あなたは同じ比で右方向(right)および上方向(up)ベクトルをセットしなければならない。640/480 = 4/3であるから、この正方形ピクセルモードにおいて、その比は等しい。 しかしながらすべてのディスプレイモードが正方形ピクセルを使うわけではない。例えばIBM VGA モードの320x200やAmigaの 320x400 モードは正方形ピクセルを使わない。これらの2つのモードはまだ4/3のアスペクト比のイメージを生ずる。したがって、そのようなハードウェアで見るつもりのイメージはそれらの上方向(up)および右方向(right)ベクトルに関してはまだ4/3の比率を使わなければならないが、しかし、+Wと+Hの設定は4/3でないだろう。 例えば: camera { location <3,5,-10> up <0,1,0> right <1,0,0> look_at <0,2,1> } これは、完全に正方形のイメージを指定する。SVGAのような正方形ピクセルのディスプレイであなたは、+W 480の+H 480か+W 600の+H 600のような+Wと+Hの設定を使うだろう。しかしながら、非正方形ピクセルのAmigaの 320x400 モードでは、あなたは正方形のイメージを表現するために+W 240 +H 400 を使いたいだろう。 7.4.4.5.2 ハンドネス(Handedness:利き手) 右方向(right)ベクトルはまた、カメラの右方向を記述する。それはPOV-Rayにあなたのスクリーンの右側がどちらかを告げる。右方向(right)ベクトルの符号は使われている座標系のハンドネス(右手系か左手系か)を決める。デフォルトのright構文は: right <1.33, 0, 0> これは+x-方向が右であることを意味する。これは左手系(left-handed system)と呼ばれる。なぜなら、あなたは軸の進路を保持するためにあなたの左手を使うことができる。あなたの左手を手のひらがあなたの右側を向くようにしなさい。あなたの親指を上へ指しなさい。あなたの人さし指でまっすぐ先を示しなさい。あなたの他の指で右側を示しなさい。あなたの曲がった指は、+x-方向を指している。その時、あなたの親指は、+y-方向を示し、あなたの人さし指は、+z-方向を示す。 いくつかのCADプログラムと他のレイトレーサーで一般に普及している右利きの座標系を使うためにあなたの右手を使って同じ形を作りなさい。あなたの親指はまだ上の+y-方向を指していて、あなたの人差し指はまだ前方の+z-方向を指しているが、あなたの他の指の指す +x-方向は左になる。これはあなたのスクリーンの右側がx-方向になったことを意味する。POV-Rayにこのように行うように指示するために、あなたは以下のように負のx値を右方向(right)ベクトルに使うことができる。 right <-1.33, 0, 0> 左に向かって増加するxは2Dスクリーンでは大きな意味を持たないから、あなたはあなたのカメラのlocationの中に正のz値を用いて、すべてのものを180度回転する。あなたは、何かこのようなもので終える。 camera { location <0,0,10> up <0,1,0> right <-1.33,0,0> look_at <0,0,0> } 今、あなたがあなたのレイトレーサーのエアロビクスをする時、セクション「POV-Rayの座標形を理解する」で説明したように、あなたは、あなたの右手を回転の方向を決めるのに使う。 二次元の格子の中では、xは常に右でyは上である。zが画面の中を指すのか外を指すのかと、現実の世界の上がコンピュータモデルのどの軸と関係するのかという質問から、ハンドネスの2つのバージョンが生じる。 AutoCADのような建築用のCADシステムでは、神の目(God's Eye)の方位を使う傾向があり、z-軸が高度であって、それはモデルの上に向かう方向である。あなたがコンピュータ画面上で建物の青写真を見ている建築家であるならば、このアプローチは意味をなす。 z は上を意味し、それはあなたに向かって増加する、xとyはまだ画面を横切り、画面上にある。これは基本的な右手系である。 スタンドアロンのレンダリングシステムでは、POV-Rayのように、あなたを参加者のように考える傾向がある。まるであなたがシーンに立っているカメラマンであったかのように、あなたは画面を見ている。モデルの上は今度はyであり、現実の世界の上と同じであり、xはまだ右であり、従ってzは深さで無ければならず、それはあなたから離れてスクリーンの中にゆくほど増加する。これが基本的な左手系である。 7.4.4.6 カメラを変換する(Transforming the Camera) translate(平行移動)およびrotate(回転)コマンドで一度あなたが定義したカメラを再配置できる。例えば: camera { location < 0, 0, 0> direction < 0, 0, 1> up < 0, 1, 0> right < 1, 0, 0> rotate <30, 60, 30> translate < 5, 3, 4> } この例では、カメラ(camera)が作成され、30度x-軸まわりに、60度y-軸まわりに、そして30度z-軸まわりに回転され、それから空間上の別の点に平行移動される。 7.4.5 カメラ(Camera)識別子 あなたは、もしあなたが望むなら、いくつかのカメラ識別子を宣言することもできる。これは、す速くカメラを変更することを容易にする。例えば: #declare Long_Lens = camera { location -z*100 angle 3 } #declare Short_Lens = camera { location -z*50 angle 15 } camera { Long_Lens // レンズを交換するためにこの行を編集せよ look_at Here } 7.5 オブジェクト(Objects) オブジェクトは、あなたのシーンの基本単位である。POV-Rayがサポートする多くのいろいろなオブジェクトがある: 有限立体プリミティブ、有限パッチプリミティブ、無限立体多項式プリミティブおよび光源。また、構成的立体幾何（CSG）もサポートされる。 オブジェクトの基本的構文は、そのタイプを記述するキーワード、さらにその位置あるいは形状を定義するいくつかの浮動小数点数、ベクトルあるいは他のパラメータ、およびテクスチャ(texture)、ピグメント(pigment)、法線(normal)、仕上げ(finish)、バウンディング(bounding)、クリッピング(clipping)あるいは変換(transformations)等のいくつかのオプションのオブジェクト修飾子である。 テクスチャ(texture)は、オブジェクトが何のように見えるか記述する、つまりその素材である。ピグメント(pigment)は、その素材の本来の色あるいはカラーパターンである。法線(normal)は、表面法線ベクトルを修正することによって凹凸、くぼみ、波紋や波などのいろいろなパターンをシミュレートする方法である。仕上げ(finish)は、材料の反射および屈折特性を記述する。ハローは、オブジェクトの内部を記述するために使われる。 バウンディング形状(Bounding shapes)は有限で見えない形状であり、レンダリング時間をスピードアップするために、複雑でレンダリングの遅い形状を包む。クリッピング形状(Clipping shapes)は中身のない(hollow)内部をさらすために形状の一部を切り離すために使われる。変換(Transformations)は、どのように動かすか、ある大きさに作るか、シーンの中で形状やテクスチャを回転させるかをレイトレーサーに教える。 (訳注:さまざまなオブジェクトのサンプルはディレクトリpov3demo\objectsにある。 SOR1.POV:回転面 FRACTAL1.POV:フラクタル FRACTAL2.POV:フラクタル FRACTAL3.POV:フラクタル FRACTAL4.POV:フラクタル LATHE1A.POV:レイズ LATHE1B.POV:レイズ LATHE1C.POV:レイズ LATHE2.POV:さまざまなレイズオブジェクト SUPEREL1.POV:さまざまな立方体型超二次楕円体 SUPEREL2.POV:さまざまな円筒型超二次楕円体 SUPEREL3.POV:さまざまな超二次楕円体 PRISM1.POV:プリズム PRISM2.POV:プリズム PRISM3A.POV:線形補間によるプリズム PRISM3B.POV:2次スプライン補間によるプリズム PRISM3C.POV:3次スプライン補間によるプリズム TTF1.POV:チェッカー平面に浮かぶ"POY-Tay"のTTFテキスト TTF2.POV:フォントの異なるTTFテキスト TTF3.POV:空に浮かぶTTFテキスト TTFTEST.POV:TTFテキスト一覧 ROBOTMSH.POV:メッシュによる工作ロボット TRIMESH1.POV:三角形メッシュのテクスチャ付け CHESMSH.POV:メッシュによるチェスの駒 TORUS1.POV:トーラス BLOB1A.POV:くぼんだブロブ BLOB1B.POV:ブロブ BLOB1C.POV:ブロブ TBLOB.POV:三つの透明なブロブ POLYGON.POV:ポリゴンによる"POV"の文字 ) 7.5.1 中空(Empty)オブジェクトと中実(Solid)オブジェクト あなたがPOV-Rayの中空(empty)と中実(solid)オブジェクトの基本的な概念を知ることはハローや半透明性(translucency)のような機能がどのように使われるかを完全に理解するために重要である。 POV-Rayのオブジェクトはいずれも中実(solid)、中空(empty)あるいは(小さい)粒子(particles)で満たされたものにする事ができる。 中実オブジェクトは、そのpigmentとfinish構文（そして、いくらかの程度にそのnormal構文）によって指定された材料から作られる。デフォルトで、すべてのオブジェクトは、中実と仮定される。あなたが石のテクスチャを球に割り当てるならば、あなたは完全に石で作られたボールを得るだろう。それは石のブロックからそのボールを切り出したようなものである。ガラス製のボールは、ガラスで作られたどっしりした球である。 あなたは、中実オブジェクトが概念上の事物であることを知っていなければならない。 あなたが例えば球の一部を切り離すと、あなたはその球が空っぽであることを見るだろう。すなわち、あなたはハッキリとその内部がからで非常に薄い表面を持つのを見るだろう。 これはPOV-Rayで使われる中実オブジェクトの概念に反してはいない。すべての球の内部空間は球の材料によってカバーされていると仮定される。従ってそこにはフォグ(fog)やハローで使われるような他の粒子のための空き場所はない。 中空オブジェクトはobject構文にhollowキーワードをつけ加えることにより作成される("Hollow"を参照 )。中空(あるいはhollow)オブジェクトはpigment、finishおよびnormal構文で指定された材料の非常に薄い表面でできていると仮定される。オブジェクトの内部は空っぽである。すなわちそれは通常、空気の分子を含んでいる。 中空オブジェクトはシーンにフォグ(fog)あるいは大気(atmosphere)を追加するかあるいはオブジェクトにハローを加えることにより粒子で満たすことができる。これはいかなる種類の粒子でオブジェクトを満たすためにも、最初に中空(hollow)にしなければならないということを理解するためには非常に重要である。 7.5.1.1 ハローの落とし穴 あなたが知っていなければならない現在の中空/中実オブジェクトのインプリメンテーション中の落し穴がある。 ハローの内部に中実オブジェクトを置くことを可能にするためには(これはまたフォグ(fog)と大気(atmosphere)にもあてはまる)、ハローを通過するすべての光をテストしなければならない。この光線が中実オブジェクトを通して移動するならば、ハローは計算されないだろう。これは、誰もが予想することである。 カメラ光線が中空(hollow)でないオブジェクトの内側にあるとき問題は起こる。この場合、光線は中実オブジェクトを通してすでに移動していて、そして、たとえハローのコンテナオブジェクトにヒットし、それが中空(hollow)だとしても、ハローは計算されないだろう。これらの二つの間の場合を教える方法がない。 POV-Rayは、カメラがコンテナオブジェクト内にあるとき、正しくハローをレンダリングすることができるために、カメラ光線をたどることに先立ちカメラがオブジェクトの内側にあるかどうか決めなければならない。これをする方法がない。 この問題の答えは（平面のような無限オブジェクトにしばしば起こるだろう）それらのオブジェクトも中空(hollow)にすることである。従って光線は中空(hollow)オブジェクトを通って移動し、コンテナオブジェクトにあたり、ハローは計算されるだろう。 7.5.1.2 屈折の落し穴(Refraction Pitfall) 屈折するオブジェクト(および屈折しない半透明オブジェクト)を扱う場合の落とし穴がある。 あなたが部分的にガラスと石で作られるオブジェクトを作成したいと想像しなさい。あなたは、表面の内側に何も見たくないので、以下のような併合(merge)か何かを使うだろう。 merge { sphere { <-1,0,0>, 2 texture { Stone } } sphere { <+1,0,0>, 2 texture { Glass } } } これのどこが悪いのか?とあなたはたずねるだろう。問題は、実際のオブジェクトの内部が何のように見えるか教える方法がないということである。これは、POV-Rayの問題ではなく、全般的な問題である。あなたは、表面ベースのモデルでオブジェクトの内部を定義することができない。あなたは、その内部が何のように見えるか決めるためにいくらかの（複雑な）規則を作成しなければならない。それは、石で作られているか？それは、ガラスで作られているか？それは、ガラスと石の間の、なにか奇妙な混合物でに作られているか？それは、半分が石で半分がガラスであるか？どこに二つの材料の間の境界があり、そして、それは何のように見えるか？ あなたは、上記のオブジェクトを見るだけでは上の質問に答えることができないだろう。あなたは、より多くの情報を必要とする。 あなたが半分が石で半分がガラスから作られたオブジェクトを作成したいならば、あなたは以下の構文を使うべきだった。 union { intersection { sphere { <-1,0,0>, 2 } plane { x, 0 } texture { Stone } } intersection { sphere { <+1,0,0>, 2 } plane { x, 0 inverse } texture { Glass } } } 石だけで作られたオブジェクトとガラスだけで作られたオブジェクトがあるので、この例は正しい。 あなたは、内部がよく定義されていないオブジェクトを決して使ってはならない。つまり、異なる屈折(および半透明)特性を持つオブジェクトに対して異なるテクスチャがあってはならない。あなたが階層化されたテクスチャを使うならば、これが最も低い層だけにあてはまるということを、あなたは知っていなければならない。 7.5.2 有限中実プリミティブ(Finite Solid Primitives) 12の異なる中実有限プリミティブ形状がある：ブロブ(blob)、ボックス(box)、コーン(cone)、円筒(cylinder)、フラクタル(fractal)、ハイトフィールド(height field)、レイズ(lathe:ろくろ)、球(sphere)、超二次楕円体(superellipsoid)、回転面(surface of revolution)、テキストオブジェクト(text object)およびトーラス(torus)。 これらはうまく定義された内部を持ち、CSGで使うことができる(セクション「構成的立体幾何」を参照)。それらは有限で自動バウンディング(automatic bounding)に応答する。すべての形は同様に平行移動でき、回転でき、拡大縮小できる。 7.5.2.1 ブロブ(Blob) (図 ブロブ) ブロブ(Blobs)は、面白くて柔軟なオブジェクトタイプである。数学的には、それらはスカラー・フィールドの等値表面(iso-surfaces)である、すなわち、それらの表面は各々の点のフィールドの強度によって定義される。この強度がしきい値と等しければ表面の上で、等しくなければそうでない。 各々のブロブコンポーネントを空間で浮いているオブジェクトとして描きなさい。このオブジェクトは、オブジェクトの中心で最大で、オブジェクトの表面ではゼロに低下するフィールドで満たされている。これらのコンポーネントのフィールドの強度は一緒に加えられブロブのフィールドを形成する。そこで、POV-Rayはこのフィールドのどこで与えられた値(しきい値)になっているかを探す。それらのすべての点がブロブオブジェクトの表面を形成する。そのしきい値よりも大きなフィールド値の点は内部であり、小さなフィールド値の点は外部と判断される。 ブロブを見る別のより簡単な方法がある。それらは有機的なblobbyに見える形状を形成するために互いに引き寄せられたり反発したりするフレキシブルなコンポーネントの結合として見ることができる。まるでそれらが蜂蜜か何かで作られたように、コンポーネントの表面は、実際に外へなめらかに伸びてつながる。 ブロブは、球形および円筒形のコンポーネントで作られて、次のように定義される： blob { threshold しきい値 cylinder { <端点1>, <端点2>, 半径, [ strength ] 強度 } sphere { <中心>, 半径, [ strength ] 強度 } [ component 強度, 半径, <中心> ] [ hierarchy FLAG ] [ sturm ] } threshold(しきい値)キーワードは、POV-Rayが見ている合計のフィールド強度の値を決める。空間に向かう光線を追跡し、個々のブロブコンポーネントをがどのように光線に影響するかを見て、POV-Rayはフィールドの強度がしきい値に等しい空間上の点を見つける。以下のリストはあなたがしきい値について知らなければならないことを示す。 1) しきい値は、正でなければならない。 2) しきい値がその強度よりも大きければそのコンポーネントは消える。 3) しきい値が大きいほど、あなたの見る表面はコンポーネントの中心に近づく。 4) しきい値が小さいほど、あなたの見る表面はコンポーネントの表面に近づく。 円筒形のコンポーネントは、底面<端点1>、頂上<端点2>と半径によって円筒を形づくるキーワードcylinderによって指定される。円筒は半球状の(hemispherical)端面を底面と頂上に持つ。球状のコンポーネントは<中心>に、与えられた半径で球を形作るsphereキーワードによって指定される。それぞれのコンポーネントは独立に平行移動、回転、拡大縮小およびテクスチャ付けができる。円筒状および球状のコンポーネントの完全な構文は: sphere { <中心>, 半径, [strength] 強度 [ translate <ベクトル> ] [ rotate <ベクトル> ] [ scale <ベクトル> ] テクスチャ修飾子 } cylinder { <端点1>, <端点2>, 半径, [strength] 強度 [ translate <ベクトル> ] [ rotate <ベクトル> ] [ scale <ベクトル> ] テクスチャ修飾子 } 不均一に球形のコンポーネントを拡大縮小することによって、あなたは楕円体状のコンポーネントを作成することができる。componentキーワードは球状のコンポーネントを与えるが、それはもっぱら初期のPOV-Rayバージョンとの互換性のために用いられる。 strengthパラメータは浮動小数点数値でオブジェクトの中心のフィールド強度を指定する。この強度は正でも負でも良い。正の値はそのコンポーネントが他のコンポーネントを引きつけるようにし、負の値は他のコンポーネントを追い返すようにする。異なる、別々のブロブ形状のコンポーネントは互いに影響を及ぼさない。 あなたは、以下の事を心に留めておかなければならない。 1) 強度値は、正でもよいし負でもよい。ゼロは悪い値であり、その正味の答えはフィールドがまったく加えられないということである-まるであなたがこのコンポーネントを使わなかったかも知れなかった。 2) もし強度が正の場合POV-Rayはコンポーネントのフィールドをコンポーネントの中心のまわりの空間に加えるだろう。もし強度が"しきい値"より大きくなるほど十分にこれが加えられれば、あなたは表面を見るだろう。 3) もし強度値が負であるならば、POV-Rayはコンポーネントのフィールドをコンポーネントで中心のまわりの空間から減ずるだろう。これは、正のコンポーネントがすぐ近くにあるということが起きる場合のみ何かをするだけである。何が起こるかというと、すぐ近くの正のコンポーネントのまわりの表面が、負のコンポーネントの中心から離れてくぼまされる。 各々のブロブオブジェクトのコンポーネントは、ブロブの交差判定と他の操作のスピードアップのために球形のバウンディング階層(bounding hierarchy)によって内部的にバウンディングされる。オプションのキーワードhierarchyを使うことによって、あなたはこの階層(hierarchy)をoffにできる。 3つのコンポーネントのブロブの例は、以下の通りである: blob { threshold 0.6 sphere { <.75, 0, 0>, 1, 1 } sphere { <-.375,.64952, 0>, 1, 1 } sphere { <-.375, -.64952, 0>, 1, 1 } scale 2 } 一つのブロブコンポーネントがあるとき、あなたの見る表面は用いたオブジェクトのように見えるだけである。つまり、球あるいは円筒で、表面はコンポーネントのために指定した表面よりもなんだか内側になっている。正確な表面の位置は、以下にリストしたブロブ方程式から決定できる。(あなたはたぶんこれを知っている必要は全くないであろう。ブロブは正確なモデリングより視覚的なアピールのためにある)。 より数学的なことを気にする人のために、POV-Ray内部でブロブを作成するために使われた公式がここにある。あなたは、ブロブを使うためにこれを理解する必要がない。一つのブロブコンポーネントのために使われた公式は、以下の通りである: density = strength * (1 - radius^2)^2 この数式には素晴らしい特性がある。それはコンポーネントの中心で正確にstrengthパラメータに等しい。そしてコンポーネントの中心から半径に等しい距離で0に落ちる。1つより多いブロブコンポーネントの密度の数式は、単に個々のコンポーネントの密度を加えるだけである: density = density1 + density2 +... ブロブのための計算は非常に正確でなければならない。もしこの形状が不適当にレンダリングされるのならば、あなたは、POV-Rayの遅くなるけれどもより正確なステュルムの求根法(Sturmian root solver)を用いるために、キーワードsturmを最後のコンポーネントに加えても良い。 7.5.2.2 ボックス(Box) (図ボックス) 単純なボックスは、このようにボックスの2つの角をリストすることによって定義することができる: box { <コーナー1>, <コーナー2> } 図 ボックスの幾何 ここで <コーナー1> および <コーナー2> はボックスの対角コーナーのx、y、z座標を定義するベクトルである。 すべてのボックスは、それらの、座標軸と平行な面で定義されることを注意する。それらはキーワードrotateを用いて任意の方向に後で回転させることができる。 <コーナー1>のそれぞれの要素は常に<コーナー2>の対応する要素よりも小さくなければならない。もし<コーナー1>の要素が一つでも<コーナー2>より大きいとそのボックスはシーンに現れない。 ボックスは効率的に計算でき、良いバウンディング形状を作る(もしマニュアルなバウンディングが必要そうならば)。 7.5.2.3 コーン(Cone) (図　コーン) 有限長のコーン(円錐)あるいは切頭体(frustum)（頂点を切り取った円錐）は cone { <底面点>,底面半径, <上面点>, 上面半径 [ open ] } で定義されるだろう。 図 コーンの幾何。 ここで<底面点>および<上面点>はコーン底面とキャップの中心のx、y、z座標を定義するベクトルであり、"底面半径"と"上面半径"は対応する半径の浮動小数点数値である。 通常コーンの端は互いに平行でコーンの長さ方向に垂直な平面で閉じている。オプションのキーワードopenを"上面半径"の後ろに追加すると、端面は取り除かれ、結果はメガホンか漏斗のような傾斜のついた中空のチューブになる。 7.5.2.4 円筒(Cylinder) (図　円筒) 平行な端面を持つ有限長の円筒は cylinder { <底面点>, <上面点>, 半径 [ open ] } で定義されるだろう。 図 円筒の幾何 ここで<底面点>と<上面点>は円筒の底面と上面のx、y、z座標を定義するベクトルであるり、 "半径"は半径の浮動小数点数値である。 通常、円筒の端面は互いに平行で円筒の長さ方向に垂直な平面で閉じている。オプションのキーワードopenを半径の後ろに加えると、端面は取り除かれ、結果は中空のチューブになる。 7.5.2.5 ハイトフィールド(Height Field) (図 ハイトフィールド) ハイトフィールドは高速で、効率的なオブジェクトであり、一般にメッシュにおける膨大な三角形無しで山脈や他の凹凸した表面を作るのに使われる。 ハイトフィールドの構文は: height_field { ファイルタイプ "ファイル名" [ hierarchy ブール ] [ smooth ブール ] [ water_level 浮動小数点数 ] } ハイトフィールドは本質的には上面に山脈なような表面を持つ1単位の幅で1単位の長さの正方形である。各点における山脈の高さはグラフィックイメージのピクセルのカラー番号かパレットインデックスからとられる。最大の高さは1で、イメージファイル内の最大のカラー番号あるいはパレットインデックス値に対応する。 ________ <- イメージインデックス255 (16-bitイメージでは 65535 ) / /| +1y -- | | | | | | |+1z <- イメージの右上 | | / 0,0,0-- +1x ^ |____ イメージの左下 図 () 拡大縮小されていないハイトフィールドのサイズと方位 三角形のメッシュは、直接イメージファイルの中のピクセルに対応する。4つの近隣ピクセルによって形づくられた各々の正方形は、2つの三角形に分割される。解像度N*Mピクセルのイメージは(N-1)*(M-1)の正方形を持ち、それは2*(N-1)*(M-1)の三角形に分割される。 図 画像の4ピクセルと結果として生ずるハイトフィールドの高さと三角形 ハイトフィールドの解像度は、2つの要因によって影響される：イメージの解像度とカラー/インデックス値の解像度である。イメージのサイズは、x-とz-方向の解像度を決める。より大きいイメージは、より多くの三角形を扱い、そして、よりなめらかに見える。カラー/インデックス値の解像度は、y-軸に沿った解像度を決める。8bitのイメージから作られたハイトフィールドは256の異なる高さのレベルを持ち、16bitのイメージからのものは65536までの高さのレベルを持つ。このように、2番目のハイトフィールドはもしそのハイトフィールドが適当に作成されれば、y-方向についてよりスムーズに見える。 イメージのサイズ／解像度はハイトフィールドのサイズには影響しない。拡大縮小されていないハイトフィールドのサイズは常に1 x 1である。より高い解像度のイメージ ファイルはより小さい三角形を作るのであり、より大きなハイトフィールドを作るわけではない。 以下のように、ハイトフィールドを定義できる6つかおそらく7つのタイプのファイルがある: height_field { gif "filename.gif" } height_field { pgm "filename.pgm" } height_field { png "filename.png" } height_field { pot "filename.pot" } height_field { ppm "filename.ppm" } height_field { sys "filename.???" } height_field { tga "filename.tga" } ハイトフィールドを生成するために使われるファイルは、GIF、TGA、POT、PNG、PGM、PPMおよびたぶんシステム(つまり Windows BMP あるいは Macintosh Pict)のフォーマットのファイルが可能である。GIF、PNG、PGMおよびたぶんシステムフォーマットファイルは標準のペイントプログラムで作成したものだけが可能である。TGAイメージファイルを作成可能なペイントプログラムもあるが、それらはPOV-Rayが使う特殊な16ビットTGAファイルを作成するために使えるものは多くはないだろう(詳しくは後述と"HF_Gray_16"を見て欲しい)。 カラーパレットを使うGIFのようなイメージファイルでのカラー番号は、与えられたピクセルでのパレットインデックスである。GIFイメージのパレットを見るためにペイントプログラムを使いなさい。最初のカラーはパレットインデックス0であり、二番目はインデックス1であり、第三はインデックス2であり、そして、その他である。最後のパレットエントリは、インデックス255である。イメージの中で低いパレットエントリを用いる部分はハイトフィールドの低い部分となる。高いパレットエントリを使っているイメージの部分はハイトフィールドの高い部分になる。 GIFファイルから作成されたハイトフィールドは、GIFファイルの最大カラー番号が256であるから、256の異なる高さしか持つことができない。 パレットエントリの色はピクセルの高さには影響しない。カラーエントリ0が赤でも、青でも、黒でもあるいはオレンジでもカラーエントリ0を用いているピクセルの高さは常に0である。カラーエントリ255が藍色でも、ホットピンクでも、白あるいはスカイブルーでもカラーエントリ255を用いているピクセルの高さは常に255である。 あなたはハイトフィールドGIFイメージをペイントプログラムあるいはFractintのようなフラクタルプログラムを用いて作ることができる。あなたは大抵、Fractintを大部分のPOV-Rayと同じ入手先から得ることができる。 POTファイルは本質的には16bitパレットのGIFファイルである。POTファイルの最大色数は65536である。これはPOTハイトフィールドが65536までの可能な高さ値を持つことを意味する。これはよりスムーズなハイトフィールドを作ることを可能にする。より細かい中間の値が可能になったとしてもハイトフィールドの最大高さはまだ1のままであることに注意して欲しい。 これを書いている段階では、POTファイルを作成できるプログラムはフリーウェアのIBM-PC プログラムFractintだけである。 このフラクタルプログラムで生成されたPOTファイルはファンタジックな風景を作成する。 TGAとPPMファイルフォーマットは、イメージファイルというよりはむしろ16ビット数の記憶装置に使われるかもしれない。これらのフォーマットは各ピクセルの赤と緑のバイトを、高さ値の上位バイトと下位バイトを保存するために使う。これらのファイルはPOTファイルと同じようにスムーズであるが、それらは特別なカスタムメイドのプログラムで作成しなければならない。gforge と Terrain MakerのようないくつかのプログラムがPOV-Rayが使うフォーマットでTGAハイトフィールドを作成できる。 PNGフォーマットは通常グレイスケールの形式で保存され、黒はハイトフィールドの低い場所に白は高い場所に対応する。PNGファイルはグレイスケールイメージで16 bitsまでの保存ができるので、それらはTGAおよびPPMイメージと同じようにスムーズである。これらはあなたが通常のイメージビューアーで見ることができるグレイスケールイメージである。gforgeは16-bitのハイトフィールドをPNGフォーマットで作成できる。カラーPNGイメージはTGA や PPM イメージと同様の方法で使うことができる。 SYSフォーマットはプラットホーム指定のファイルフォーマットである。詳しくはあなたのプラットホーム用のドキュメンテーションを見て欲しい。 オプションのwater_levelパラメータを、ファイル名の後に付け加えてもよい。それはキーワードwater_levelとそれに続く浮動小数点数値からなり、その値以下のハイトフィールドの部分を無視するようにプログラムに告げる。デフォルトの値はゼロであり、正当な値は0から1の間である。例えば、water_level .5 はPOV-Rayにハイトフィールドの上半分のみをレンダリングするように告げる。残りの半分は水の下にあってとにかく見えない。この語は、景色をレンダリングするためのハイトフィールドのポピュラーな利用法から来た。ハイトフィールドが、島を作成するために使われ、別の形は、島のまわりの水をシミュレートするために使われる。ハイトフィールドの大きい部分が、水によっておおい隠される。そこで、water_levelパラメータは、ハイトフィールドの目に見えない部分を無視することをレイトレーサーに許すために導入された。また、water_levelはハイトフィールドの中で不必要なより低い値を切り捨てるために使われる。例えば、あなたが単一色の背景の上にフラクタルのイメージを有し、その背景色のパレットエントリが0であれば、あなたはwater_level .001 を指定することにより、ハイトフィールドの中の背景を取り除くことができる。 通常、ハイトフィールドは、それらがたくさんの平らな三角形で作られるので、粗い、ギザギザな外観を有する。キーワードsmoothを加えることは、POV-Rayに三角形のライティングとシェーディングをスムーズな外観にするような方法で、三角形の表面法線ベクトルを修正させるようにする。これはあなたに他で必要とされるよりも、ハイトフィールドのためにより低い解像度のファイルを使うことを許す。しかしながら、スムーズな三角形は長いレンダリング時間がかかる。 交差判定をスピードアップするために、１レベルのバウンディング階層(one-level bounding hierarchy)が利用できる。デフォルトでそれらは常に使われるが、小さいハイトフィールド(例えば低い解像度のイメージ)に対してはスピードアップのために結局はoffに切り換えることができる。 (訳注:ハイトフィールドの他のサンプルはpov3demo\other\crater.pov参照) 7.5.2.6 ジュリアフラクタル(Julia Fractal) (図 ジュリアフラクタル) ジュリアフラクタルオブジェクトは、古典的なジュリア集合を生成するのに使われた方法を一般化して作成された4-Dオブジェクトの3-Dスライスでである。あなたは、ねじられたタフィー(taffy:一種のキャンディー)の奇妙なブロブ(bizarre blobs)のように見えるいくつかを含む、julia_fractalを使って妙なオブジェクトの幅広い多様な種類を作ることができる。 julia_fractal 構文(デフォルト値はコメントにリストする) は: julia_fractal { 4Dジュリアパラメータ // デフォルトは<1,0,0,0> [ quaternion | hypercomplex ] // デフォルトはquaternion [ sqr | cube | exp | reciprocal | sin | asin | sinh | asinh | cos | acos | cosh | acosh | tan | atan | tanh | atanh | log | pwr(X,Y) ] // デフォルトはsqr [ max_iteration 最大反復回数 ] // デフォルト値は20 [ precision 精度 ] // デフォルト値は20 [ slice 4D法線, 距離値 ] // デフォルトは <0,0,0,1>,0 } 4-Dベクトル"4Dジュリアパラメータ"は、反復公式f(h)＋pの中の古典的なジュリアパラメータpである。 ジュリアフラクタルオブジェクトは、4-D空間の任意の点h(0)がオブジェクト内部にあるか外部にあるかどうか決めるアルゴリズムを使うことによって計算される。アルゴリズムは、...公式 h(n+1) = f(h(n)) + p (n = 0, 1,..., max_iteration-1) を反復することによってベクトルh(0)（h(1)）のシーケンスを生成することを必要とする。ここで p はジュリアフラクタルの固定 4-D ベクトルパラメータで、f()は関数 sqr、cube、...の一つで、対応するキーワードの存在によって指定される。シーケンスの始まりの点h(0)はもしシーケンス内のベクトルが、反復がmax_iteration値に到達する前に、一つも原点から半径4の多元球から逃れない場合、ジュリアフラクタルオブジェクトの内部とみなされる。あなたがmax_iterationを増加すると、いくつかの以前は逃れなかった点が逃れるようになり、ジュリアフラクタルを形成する。"ジュリアパラメータ"に依存し、ジュリアフラクタルオブジェクトは必ずしも連結しない;それは、拡散させられたフラクタルダストであってもよい。低いmax_iterationを使うことは、中実オブジェクトを作るために一緒にダスト(dust:ちり)を溶解することができる。高いmax_iterationは、より正確だが、レンダリングを遅くする。たとえそれが正確でないとしても、あなたが低い最大繰り返し数の値で得る中実形は、とても面白いものになる。 このアルゴリズムで記述された数学的オブジェクトが4次元であることから、４次元から3次元にオブジェクトの次元数を減らす方法がなければならない。これは、スライスフィールドによって定義された三次元の平面により4-Dフラクタルを横切って、それから三次元の空間に交差を投影することによって達成される。スライス平面は、法線4Dに垂直で、原点から"距離値"単位である三次元の空間である。長さがゼロの法線4Dベクトルあるいは4番目の成分が0の法線4Dベクトルは違法である。 あなたは、スライスの"距離値"パラメータを変えるためにPOV-Rayのアニメーション機能を使うことによってジュリアフラクタルの4次元の性質に対するよい感じを得ることができる。あなたは、"距離値"の変化につれて、3-Dオブジェクトの断面が平面を通り抜けるように変化し、何もないところから現れ、成長し、何もない物へ縮むジュリアフラクタルを作れる。 "精度(precision)"パラメータは、ある点がフラクタルオブジェクトの内部か外部かの決定で使われる許容限界量である。大きな値はより正確な結果を与えるがレンダリングは遅くなる。フラクタルオブジェクトの外観が目に見えるほど品位低下しない限りできるだけ低い値を使って下さい。 キーワードquaternion(４元) あるいは hypercomplex(多元)の存在はどちらの4-D方程式をフラクタルの計算に用いるかを決める。両者は複素数の4-Dへの一般化であるが、いずれもすべてのフィールド(界)特性は満たさない(実数と複素数のすべての特性は、われわれの多くが高校で葬った)。４元数(Quaternions)は非可換(non-commutative)の乗算を持ち、多元数(hypercomplex numbers)は、いくつかの非0要素のための逆数(multiplicative inverse)を持つのに失敗することがある(あなたが、すべてのフィールド特性を損なわずに、うまく複素数を四次元に一般化することができないということが証明されているので、何かは壊されなければならない)。これらの方程式は両方とも19世紀に発見された。2つの中で、４元数の方がよりよく知られているが、sin、cos、などの複素数関数が多元数に対して機能するように一律に一般化できるので、多元数の方が我々の目的のためにはより利用しやすいと論ずることができる。 数学的好奇心の強い人のために、これらの2つの方程式(algebras)の代数特性は、単位基底ベクトル(unit basis vectors)1= <1,0,0,0>、i=<0,1,0,0>、j=<0,0,1,0>およびk=<0,0,0,1>の乗算特性から導くことができる。両方程式ですべてのxについて1 x = x 1 = x (1 は乗法の単位元(identity)である)。基底ベクトル 1 および i は両方程式の中で良く知られている複素数1とiのように正確に作用する。 ４元(Quaternion)基底ベクトルの乗算規則: ij = k; jk = i; ki = j ji = -k; kj = -i; ik = -j ii = jj = kk = -1; ijk = -1; 多元(Hypercomplex)基底ベクトルの乗算規則: ij = k; jk = -i; ki = -j ji = k; kj = -i; ik = -j ii = jj = kk = -1; ijk = 1; ４元法計算で速度を上げるために距離評価(distance estimation)計算が使われる。この距離評価公式が有効であることの証明は2次元から4次元へ一般化できない。しかし、公式はとにかくうまく機能するようである。それにもかかわらず証明は無い! 関数キーワード sqr、cube、などのいずれかの存在は反復公式 h(n+1) = f(h(n)) +p において、どの関数がf(h)に使われるかを決める。ほとんどの関数キーワードはhypercomplexキーワードがある場合しか機能しない。sqrとcubeだけがquaternionsとともに機能する。関数はすべて良く知られている複素関数で、四次元に一般化されている。 関数キーワード 4-D 値 h のマップ: ================================================ sqr h*h cube h*h*h exp e の h乗 reciprocal 1/h sin hの正弦 asin hのアークサイン sinh hのハイパーボリックサイン asinh hの逆ハイパーボリックサイン cos hの余弦 acos hのアークコサイン cosh hのハイパーボリックコサイン acosh hの逆ハイパーボリックコサイン tan hの正接 atan hのアークタンジェントh tanh hのハイパーボリックタンジェント atanh hの逆ハイパーボリックタンジェント log hの自然対数 pwr(x,y) hの複素x+iyべき乗 ジュリアフラクタルの簡単な例は: julia_fractal { <-0.083,0.0,-0.83,-0.025> quaternion sqr max_iteration 8 precision 15 } ４元数を用いたジュリアフラクタルの最初のレンダリングはAlan Norton とその後John Hartによって'80年代になされた。この新しいPOV-Rayのインプリメンテーションは、多元数を使い、さまざまな優れた関数を使うために古典的なマンデルブロー(Mandelbrot)のz^2 + c式の代わりに反復公式を一般化することにより、文献の中で知られていることよりも進んでいるFractintを手本にした。余分な2つの次元とそれとともに働く18の関数を用いて、勇敢な探検家は新しいフラクタル小動物(beasties)を多次元空間(hyperspace)の中で見つけることができるべきなので、それを備えている! 7.5.2.7 レイズ(Lathe) (図() レイズ) レイズ（lathe:ろくろ、旋盤）は、2次元の曲線を軸について回転させることから生成されるオブジェクトである。その曲線は線形、2次あるいは3次スプライン曲線により結合される点の集合として定義される。構文は: lathe { [ linear_spline | quadratic_spline | cubic_spline ] 点の数, <点_1>, <点_2>,..., <点_n> [ sturm ] } パラメータ"点の数"はいくつの2次元の点が曲線を形成するかを決める。これらの点はオプション(デフォルトはlinear_splineである。)の指定に従って、線形、2次あるいは3次スプラインによって結合される。曲線は自動的には閉じられない、つまり最初と最後の点は自動的には結ばれないので、閉じた曲線が欲しい場合はあなた自身でそうしなければならない。このように定義された曲線はy-軸まわりに回転され、原点をその中心とするレイズオブジェクトを形作る。 以下の例は薄い円筒(つまり薄い壁の円筒)のような、簡単なレイズオブジェクトを作る。 lathe { linear_spline 5, <2, 0>, <3, 0>, <3, 5>, <2, 5>, <2, 0> pigment {Red} } 円筒は内半径2で外半径3であるから、壁の厚さは1で、高さは5で原点に位置することを示す。つまり、回転軸はy-軸である。最初と最後の点が等しいので閉じた曲線になることに注意してほしい。 レイズとプリズム(prism)オブジェクトで用いられるスプラインは理解するのがちょっと難しい。スプラインの基本的なコンセプトは与えられた点列を通る曲線を決める方法である。線形スプラインはそれが連続的な点を直線で結ぶ以外の何者でもないため、最もシンプルなスプラインである。これは2点間を結ぶ際にただその2点だけに依存することを意味する。それ以上の情報は考慮しない。2次および3次スプラインは2点を結ぶ場合、それらが反対の点を考慮するだけでないと言う点で異なるが、それらはよりスムーズに見え-3次スプラインの場合は-各点でよりなめらかな変化を生じる。 2次スプラインは2次曲線で作られる。それらのそれぞれは、2つの連続点をつなぐ。それらの2つの点(それらを2番目、3番目と呼ぼう)では2次曲線を記述するには十分でないので、3番目の点の前※の点(predecessor)が曲線を描く際に考慮される。(※訳注:次では？) 数学的には3番目と4番目の点の関係(それらの2-D平面上での位置)は3番目の点での曲線の傾きを決める。2番目の点での曲線の傾きは制御できない。したがって、二次スプラインは線形のスプラインより非常になめらかに見える。しかし、点の両側での傾斜が異なるので、各々の点での変化は一般になめらかでない。 三次のスプラインは、2番目と3番目の点の間にカーブを描いているとき最初の点も考慮するので、2次スプラインの変化問題を克服する。今、二番目の点での傾斜は抑制されて、各々の点でなめらかな変化を可能にする。したがって、3次スプラインは、最も柔軟でなめらかなカーブを生じる。 スプラインセグメント(すなわち2点間の曲線)の数が用いるスプラインタイプに依存することを注意しなければならない。線形スプラインに対して、あなたは点P_i, i=1,...,nを結ぶn-1のセグメントを得る。2次スプラインはn-2セグメントを与える。なぜなら最後の点は上で説明したように傾きを決めるのに用いられるだけだからである(したがってあなたは2次スプラインを決めるために少なくとも3点が必要である)。3次スプラインではあなたは最初と最後の点が傾きの計算にだけ用いられるのでn-3セグメントを得る(したがって少なくとも4点が必要である)ということが同様にあてはまる。もしあなたが端点でスムーズに変化する閉じた2次および3次スプラインが 欲しいのならば、3次の場合P_{n-1} = P_2 (閉じた曲線を得るために)、P_n = P_3 および P_{n-2} = P_1 (変化をスムーズにするために)を確認してほしい。2次の場合はP_{n-1} = P_1 (閉じた曲線を得るために) および P_n = P_2(変化をスムーズにするために)である。 (訳注：原文では上の文章は数式の表記にP[n-1]形式とP_{n-1}形式を用いた物が完全に重複している。この翻訳では後者のみを掲載する) もし、2次スプラインレイズで形状が正しく表現されない場合は、遅いがより正確なステュルムの求根法を使ってもよい。線形スプラインレイズでは2次多項式が解かれなければならないのでステュルムの求根法は必要ない。3次スプラインでは6次の多項式を解かなければならないのでステュルムの求根法が常に使用される。 7.5.2.8 プリズム(Prism) (図 プリズム) プリズム(prism、柱)は一つ以上の2次元の閉じた曲線を軸に沿ってスウィープすることにより生成されるオブジェクトである。これらの曲線は線形、2次および3次スプラインで結ばれる点の集合で定義される。 プリズムの構文は: prism { [ linear_sweep | conic_sweep ] [ linear_spline | quadratic_spline | cubic_spline ] 高さ1, 高さ2, 点の総数, <点_1>, <点_2>,..., <点_n> [ open ] [ sturm ] } プリズムオブジェクトでは一つのprism構文の内部に任意の数のサブプリズムを使うことが許される(それらは同じスプラインおよびスウィープタイプである)。偶数のサブプリズムがどこで重なっても全体が現れる。 プリズムオブジェクトの構文は、使われるスプライン曲線のタイプに依存する。以下に線形スプラインプリズムの構文を与える。 prism { linear_spline 高さ1, 高さ2, 点の総数, , ,..., , , , ,..., , , , ,..., , , ... } それぞれのサブプリズムはサブプリズムの点列の最後にサブプリズムの最初の点を繰り返すことにより、閉じていなければならない。もしそうでない場合、警告が出され、そのプリズムは無視される(線形プリズムにおいては自動的に閉じることが行われる)。これは、プリズムのすべての点が異なることを意味する(もちろん最初と最後の点は除く)。2次および3次のスプラインの制御点は任意に選ぶことができるけれども、これはすべてのスプラインタイプに適用される。 もし、サブポリゴンの点列の最初と最後の点が等しくなければ - ちょうどポリゴン構文の最後のサブポリゴンのように - 線形スプラインのプリズムの最後のサブプリズムは自動的に閉じられる。このことはポリゴンとプリズムの間の変換を容易にする。2次および3次スプラインは決して自動的には閉じられない。 2次スプラインプリズムの構文は: prism { quadratic_spline 高さ1, 高さ2, 点の総数, , , ,..., , , , , ,..., , , , , ,..., , , ... } 2次スプラインのサブプリズムは曲線の開始時の傾斜を決めるために、それぞれのサブプリズムの点列の先頭に付加的な制御点を必要とする。 最後でも重要な3次スプラインプリズムの構文。 prism { cubic_spline 高さ1, 高さ2, 点の総数, , , ,..., , , , , , ,..., , , , , , ,..., , , , ... } 閉じた点列に加えて、それぞれの３次スプラインのサブプリズムは曲線の最初と最後の傾きを決めるために2つの制御点を必要とする。 パラメータ"点の総数"はどのくらい多くの2次元上(ｘ−ｚ平面上)の点が曲線を形成するかを決める(これは2次および3次スプラインで必要とされるすべての制御点を含む)。プリズムオブジェクトを形成するために曲線はy-軸に沿って"高さ1"から"高さ2"までスウィープ(sweep:掃引)される。デフォルトで線形のスウィーピング(sweeping)がプリズムを作るために用いられる。すなわち、プリズムの壁はx-z平面に垂直である(曲線のサイズはスウィープの間変わらない)。あなたはまた、円錐状スウィープ(conic sweeping)/conic_sweepを使うことができる。それは、スウィープ中に曲線の拡大縮小率を下げて円錐のような壁のプリズムにする。 円筒(シリンダー)のようにプリズムは通常閉じている。あなたはopenキーワードを用いてプリズムの端面(caps)を取り除くことができる。あなたがそのプリズムをCSGで使うと悪い結果を得るので、そのプリズムをCSGで使うことができなくなる。 以下の例ではケーキの一切れのようなシンプルなプリズムオブジェクトを作成する: prism { linear_sweep linear_spline 0, 1, 4, <-1, 0>, <1, 0>, <0, 5>, <-1, 0> pigment {Red} } スプラインのコンセプトの説明については、レイズ(lathe)オブジェクトの記述を読んでください。 3次スプラインプリズムの形状が正しく表示されない場合は、遅いがより正確なステュルムの求根法を使っても良い。線形および2次スプラインプリズムはステュルムの求根法を必要としない。 7.5.2.9 球(Sphere) (図 球) 球オブジェクトの構文は: sphere { <中心>, 半径 } 図　球の幾何 ここで<中心>は球の中心のx、y、z座標を指定するベクトルであり、"半径"は半径を指定する浮動小数点数値である。球は楕円体形状を与えるような不均一な拡大縮小を行っても良い。 球は高度に最適化されているので、良いバウンディング(bounding)形状を作る(もしマニュアルでバウンディングが必要そうな場合)。 7.5.2.10 超二次楕円体(Superquadric Ellipsoid) (図 超二次楕円体) 超二次楕円体は二次楕円体の拡張である。これは角の丸いボックスや円筒および他の面白い形を作るのに使える。数学的には以下の方程式で与えられる: f(x, y, z) = (|x|^(2/e) + |y|^(2/e)) ^ (e/n) + |z|^(2/n) - 1 = 0 eおよびnの値は、east-west(東西)およびnorth-south(北南)指数と呼ばれ、超二次楕円体の形状を決める。両者は0より大きくなければならない。すなわち球はe = 1 および n = 1で与えられる。 原点に位置する超二次楕円体の構文は: superellipsoid { } 2つの便利なオブジェクトは角のとれたラウンドボックス(rounded box)とラウンド円筒(rounded cylinder)である。これらは、以下ような方法で宣言される。 #declare Rounded_Box = superellipsoid { } #declare Rounded_Cylinder = superellipsoid { <1, r> } 丸さ(roundedness) r は辺の丸さを決め、0より大きく1より小さくなければならない。あなたがrに小さな値を選ぶと、より小さくよりシャープな辺を得る。 eとnの非常に小さな値は求根法(ステュルムの求根法は使えない)において問題を引き起こす。 7.5.2.11 回転面(Surface of Revolution) (図 回転面) 回転面(SOR)オブジェクトは関数のグラフを一つの軸のまわりに回転させて得られる。その関数は回転軸軸上の点からの半径の従属状態(dependence)を記述する。SORオブジェクトの構文は: sor { 点の数, <点0>, <点1>,..., <点n-1> [ open ] [ sturm ] } 点 <点0>から<点n-1>までは半径と対応する高さ、すなわち回転軸上の位置からなる2次元ベクトルである。これらの点はなめらかに結合され(曲線は指定された点を通る)、y-軸に関して回転されSORオブジェクトを形成する。最初と最後の点は、曲線の始点と終点に置ける傾きを決めるために使われるだけである。SORオブジェクトで用いられる曲線はレイズオブジェクトで用いられるスプラインと類似しているある。違いはSORオブジェクトは柔軟性に欠ける点である。なぜなら数学的関数の制限下にあるから、すなわち回転軸上の任意の値yに対して最大1つの値、すなわち一つの半径値しか属してはいけない。あなたは閉じた曲線をSORオブジェクトにおいて回転させることはできない。 オプションのキーワード open はSORオブジェクトの上下の端面(caps)を取り除くことを可能にするもし、あなたがそうした場合、悪い結果になるので、それを CSGで使うことはもうできなくなる。 SORオブジェクトは瓶や花瓶、その他の類似のオブジェクトを作るのに便利である。シンプルな花瓶はこのようにすれば見れる: #declare Vase = sor { 7, <0.000000, 0.000000> <0.118143, 0.000000> <0.620253, 0.540084> <0.210970, 0.827004> <0.194093, 0.962025> <0.286920, 1.000000> <0.468354, 1.033755> open } すでに、より柔軟なレイズオブジェクトがあるのにSORオブジェクトの必要があるか尋ねる人があるかもしれない。理由は全く単純である。SORオブジェクトとの交差判定は3次多項式を解くことを必要とするが、レイズオブジェクトの交差判定は6次の多項式を解くことを要求される(同じ滑らかさをえるために3次スプラインを必要とする場合)。ほとんどのSORおよびレイズオブジェクトはいくつかのセグメントを持つから、これはスピードにおいて非常に大きな差となる。また、3次の多項式の根は、より正確で、見つけるのがより簡単である。 回転面オブジェクトの形状が正しく表示されない場合は、遅いがより正確なステュルムの求根法を使っても良い。 以下の説明は、回転面がどのように計算されるか知りたい数学的興味を持つ読者のためのものである。読む必要はないけれども、SORオブジェクトの理解には役立つ。 最終的なSORオブジェクトを得るためにy-軸について回転される関数は半径rおよび高さhで、以下のように与えられる r^2 = f(h) = A*h^3 + B*h^2 + C*h + D これはhに関する3次関数であるから滑らかな曲線を可能にするための十分な柔軟性を持つ。 曲線自体はn点の集合P(i), i=0...n-1で定義され、曲線のそれぞれのセグメントは一つの関数を用いて補間される。一つのセグメント j, j=1...n-3、は点P(j)から点P(j+1)まで行き、端点での傾きを決めるために点 P(j-1)とP(j+2)を使う。もしn点があるとn-3セグメントになる。このことは正しい曲線を得るために少なくとも４点が必要であることを意味する。 各セグメントにおける係数A(j)、B(j)、C(j)およびD(j)は以下の式を用いて計算される b = M * x、 ここで / \ | r(j)^2 | | | | r(j+1)^2 | b = | | | 2*r(j)*(r(j+1)-r(j-1))/(h(j+1)-h(j-1)) | | | | 2*r(j+1)*(r(j+2)-r(j))/(h(j+2)-h(j)) | \ / / \ | h(j)^3 h(j)^2 h(j) 1 | | | | h(j+1)^3 h(j+1)^2 h(j+1) 1 | M = | | | 3*h(j)^2 2*h(j) 1 0 | | | | 3*h(j+1)^2 2*h(j+1) 1 0 | \ / / \ | A(j) | | | | B(j) | x = | | | C(j) | | | | D(j) | \ / ここで r(j) は点P(j)の半径で h(j)は高さである。 以下の図は点P(i)、セグメントjの位置およびこのセグメントで定義された曲線の構成を示す。 図 n点の点構成に置けるn-3セグメントのセグメント j。これらの点は回転面オブジェクトの曲線を記述する。 7.5.2.12 テキスト(Text) (図 テキストオブジェクト) テキストオブジェクトは押し出されたブロック字体の3-Dテキストを作成する。現時点ではTrueTypeフォントだけがサポートされているが構文は将来追加されるであろう他のフォントタイプを許す。構文は: text { ttf "フォント名.TTF", "テキスト文字列", 厚さの浮動小数点数値, オフセットベクトル } ここで フォント名.ttf はTrueTypeフォントファイルの名前である。それは二重引用符でくくられた文字列リテラルか文字式である。続く文字式は実際の文字列オブジェクトのテキストである。またそれも引用符で囲まれた文字列リテラルか文字列式であっても良い。文字式については「文字列」を見て下さい。 テキストは左下、最初の文字の手前、を原点に始まり、+ｘ方向へ伸びる。テキストのベースラインはx-軸をたどり、デッセンダー(descenders:小文字のベースラインより下に出る部分)はy-方向へ落ちる。文字の前面はx-y平面に位置し、テキストは+z方向に押し出される。前後の厚さは要求される値 "厚さの浮動小数点数値"で指定される。 文字は一般にある大きさに作られるために、1単位の垂直間隔は正しい。文字は、だいたい高さ0.5〜0.75単位である。 水平間隔は内部的に、フォントに保存されているカーニング情報を含めてPOV-Rayに扱われる。必要なベクトル"オフセットベクトル"は、各々の文字間の余分な変形を定義する。通常、あなたはこの値のためにゼロを指定すべきである。0.1*xを指定すると、各々の文字の間に追加のスペース0.1単位を置く。 印刷できる文字だけが、テキストオブジェクトの中で許される。リターン、ラインフィード、タブ、バックスペースなどの文字はサポートされない。 7.5.2.13 トーラス(Torus) (図 トーラス) トーラスはドーナッツあるいはインナーチューブ(inner tube)のように見える4次多項式(4th order quartic polynomial)の形状である。この形状はとても役に立ち、4次式は定義するのが難しいので、POV-Rayはあなたに近道をとらせ、トーラスを定義させる: torus { MAJOR, MINOR [ sturm ] } ここでMAJORは浮動小数点数値で大(major)半径を与え、MINORも浮動小数点数値で小(minor)半径を指定する。副半径はへり(rim)の横断面の半径であり、主半径は、穴の中心からへりの中心線まで広がる。トーラスは原点に作成されx-z平面内に座り、y-軸は穴を指す。 --- - - - - - - - -- +Y / / | / / | | | | |<-B->| -X-|-+X / / | __________/_ _ _ _ _ _ _ __________/ | |<--A-->| -Y A = 主半径 B = 副半径 図 トーラスの主半径と副半径 トーラスは、厚い円筒を形づくっている2つの円筒と2つのリングによって内部にバウンディングされる。このバウンディング用円筒でトーラスの交差判定のパフォーマンスは、非常に増加する。バウンディング用円筒がヒットされると、有効なトーラス交差（すなわち4次多項式を解く）に対する検査が実行されるだけである。したがって、多くの遅い求根計算は避けられる。 すべての高次多項式の計算は非常に高精度でなければならない。もしトーラスの表現が正確でなければ、POV-Rayの遅いけれどより正確なステュルムの求根法を使うためにキーワードsturmをMINOR値の後に加えても良い。 7.5.3 有限パッチプリミティブ(Finite Patch Primitives) 内部がよく定義されていない、6つの全く薄い有限オブジェクトがある。それらは、双三次パッチ、ディスク、平滑三角形、三角形、多角形とメッシュである。それらはCSG結合(union)で結合されても良いが、他のタイプのCSG(あるいはclipped_by構文の内側)では使えない。これらのタイプは有限であるから、POV-Rayはレンダリング時間をスピードアップするために、それらにおいて自動バウンディングを使用できる。すべての形と同様にそれらは、平行移動することができて、回転することができて、拡大縮小することができる。 7.5.3.1 双三次パッチ(Bicubic Patch) (図 ベジェパッチで作られたティーポット) 双三次パッチは三角形メッシュから作られた3Dの湾曲した表面である。POV-Rayはベジェパッチと呼ばれる一種の双三次パッチをサポートする。双三次パッチは以下のように定義される: bicubic_patch { type パッチタイプ flatness フラットネス値 u_steps U方向ステップ数 v_steps V方向ステップ数 , , , , , , , , , , , , , , , } キーワードtypeには浮動小数点数の"パッチタイプ"が続く。これは現在、0か1のどちらかでなければならない。タイプ0に対しては制御点だけがPOV-Rayの内部で保持される。これは最小量の記憶領域を必要とすることを意味するが、POV-Rayはパッチをレンダリングしようとするときに多くの余分な計算を実行する必要がある。タイプ1はパッチを前処理し、たくさんのサブパッチにする。これは、記憶を犠牲にしてレンダリングする際に本質的なスピードアップになる。 4つのパラメータ type、flatness、u_stepsおよびv_stepsは任意の順序で現れても良い。16のベクトルがそれらに続き、パッチを定義する制御点のx、y、z座標を定義する。パッチは4つのコーナー点、、およびに接触するが、他の12点はパッチを引っ張って引き伸ばして形にする。Bezier表面は、16の制御点によって形づくられた凸面の殻(convex hull)によって囲まれる。これは、凸面の殻特性(convex hull property)として知られている。 キーワードu_stepsとv_stepsにはそれぞれ浮動小数点数値が続く。それらは表面と形成するために最小どのくらいの数の行と列の三角形を用いるかを告げる。POV-Rayによってテストされるパッチの個々のピースの最大数は、以下から計算されることができる： sub-pieces = 2^u_steps * 2^v_steps これは、あなたが、実際にu_stepsとv_stepsを4未満に保持しなければならないことを意味する。ほとんどのパッチはu_steps 3とv_steps 3で十分細かく見え、これは64のサブパッチとなる（128の平滑三角形）。 POV-Rayがベジェパッチを処理する際、現在のパッチのピースが、長方形を装うのに十分フラットかどうか見るためにテストする。このテストを制御する構文はflatnessである。代表的なflatnessの値は0から1の範囲である(小さな値ほど遅い)。 flatnessの値が0の時、POV-Rayは常にu_steps および v_stepsまでパッチを小分けする。もしflatnessが0より大きければ、パッチが分割される度にPOV-Rayはさらに分割する必要があるかチェックするだろう。 ゼロでないflatnessを用いることには長所と短所の両方がある。長所は: - パッチがそれほどカーブしていない場合、それは検出され、POV-Rayはその間違ったピースに注目するための多大な時間を浪費せずにすむだろう。 - もし、パッチが1組の場所で大きくカーブするならば、POV-Rayはそこを分割し続け、その難しい場所に努力を集中するだろう。 最大の短所は、もしPOV-Rayがある部分で特定のレベルで分割を停止し、それが隣のパッチの部分と異なるレベルの場合、クラッキング（ひび割れ）の可能性があることである。これはあなたが通して見ることができるパッチの範囲内の斑点として象徴的に見える。これが現れることがどのくらい良くないかは、あなたがそのパッチを見る角度に高く依存する。 三角形のように、双三次パッチは、手で生成することに意味をなさない。これらの形は、特別なユーティリティによって作成されるべきである。あなたは、あなたがPOV-Rayを得た同じ供給源から、これらの形を生成するためにユーティリティを得ることができるかもしれない。 bicubic_patch { type 1 flatness 0.01 u_steps 4 v_steps 4 <0, 0, 2>, <1, 0, 0>, <2, 0, 0>, <3, 0,-2>, <0, 1 0>, <1, 1, 0>, <2, 1, 0>, <3, 1, 0>, <0, 2, 0>, <1, 2, 0>, <2, 2, 0>, <3, 2, 0>, <0, 3, 2>, <1, 3, 0>, <2, 3, 0>, <3, 3, -2> } POV-Rayの双三次パッチ(bicubic_patch)の三角形は法線の補間を使って、自動的になめらかにされる。しかし、パッチのグループをなめらかに縫い合わせる制御点を作成することはユーザ（あるいは、ユーザのユーティリティプログラム）まかせである。 7.5.3.2 ディスク(Disc:円盤) (図 ディスク) 他の、POV-Rayで利用可能な平らな有限オブジェクトはディスクである。ディスクは無限に薄く、厚さを持たない。あなたが本当の厚さでディスクが欲しいならば、あなたはとても短い円筒を使うべきである。ディスク形状の定義は: disc { <中心>, <法線>, 半径 [, 穴の半径 ] } ベクトル<中心>はディスクの中心のx、y、z座標を定義する。<法線>はその表面法線ベクトルを記述し、方向を記述する。これには半径を指定する浮動小数点数値が続く。これにオプションでディスクの中心からカットされる穴の半径を指定する別の浮動小数点数続く。 7.5.3.3 メッシュ(Mesh) (図 三角形メッシュ) メッシュ(mesh)オブジェクトは多数の三角形を効率的に保存するために用いられる。構文は: mesh { triangle { <コーナー1>, <コーナー2>, <コーナー3> [ texture { 文字列 } ] } smooth_triangle { <コーナー1>, <法線1>, <コーナー2>, <法線2>, <コーナー3>, <法線3> [ texture { 文字列 } ] } [ hierarchy フラグ ] } 任意の数の三角形(triangle)や平滑三角形(smooth triangle)を使うことができて、それらの個々の三角形はテクスチャ名を割り当てることにより個々にテクスチャ付けできる。そのテクスチャはメッシュが構文解析される以前に宣言されていなければならない。三角形あるいは平滑三角形の構文の内部でテクスチャ定義を用いることはできない。これは割り当てられたテクスチャの効率的な保存に必要な制限である。 メッシュの成分は内部的に交差判定をスピードアップするためにバウンディングボックス階層(bounding hierarchy)によりバウンディングされる。バウンディング階層はhierarchyキーワードを用いて、offに切り換えられる。これは、メモリーが少ないか、メッシュがほんの数個の三角形からなる場合のにのみするべきである。 メッシュオブジェクトのコピーは、同じ三角形データを参照するのでごくわずかなメモリーを消費する。あなたは、メモリーがあふれることなく簡単に10000の三角形メッシュの百のコピーをトレースすることができる（最初のメッシュがメモリーに適合すると仮定する）。 メッシュオブジェクトは、三角形の結合(union)に比べて2つの利点がある:メモリーの必要が少なく変換が速い。メモリ必要性は、能率的に三角形の頂点と法線をたくわえることによって減らされる。メッシュの変換の処理時間はメッシュオブジェクトの変換だけでよく、結合に必要なようなそれぞれの三角形の変換はいらないからである。 メッシュオブジェクトは、現在、三角形と平滑三角形のコンポーネントを含むことができるだけである。この制限は多角形のコンポーネントを許すなどいくらかの点で将来変更されるだろう。 7.5.3.4 ポリゴン(Polygon) (図 ポリゴン) ポリゴン(Polygons、多角形)は矩形、正方形および他の3辺以上の平面形状を作成するのに便利である。それらの構文は: polygon { 点の総数, , ,..., , , , ,..., , , , ,..., , , ... } 点からまでは最初のサブポリゴンを記述し、点からまでは２番目のサブポリゴンを記述し、そしてその他も同様である。ポリゴンはオーバーラップするしないにかかわらず、任意の数のサブポリゴンを含むことができる。偶数個のポリゴンがオーバーラップする場所では、全体が現れる。あなたが確認しなければならないのはそれぞれのそれらのポリゴンが閉じているかどうかと言うことだけである。これは、サブポリゴンの点列の終わりに、サブポリゴンの最初の点を繰り返すことによって保証される。これはサブポリゴンのすべての点が異なることを意味する。 もし(最後の)サブポリゴンが閉じていない場合、警告が出され、プログラムは自動的にそのポリゴンを閉じる。これは他のプログラムからインポートされたポリゴンが閉じていない、つまりそれらの最初の点と最後の点が等しくないかも知れないので便利である。 ポリゴンのすべての点は１つの平面上になければならない三次元ベクトルである。そうでないとエラーが生じる。あなたはまたポリゴンを記述するために2次元ベクトルを使うこともできる。POV-Rayはこの場合z値がゼロであると仮定する。 デフォルトの平面(planar)イメージマップにマッチする正方形ポリゴンはシンプルで: polygon { 4, <0, 0>, <0, 1>, <1, 1>, <1, 0> texture { finish { ambient 1 diffuse 0 } pigment { image_map { gif "test.gif" } } } //必要に応じてscaleやrotateをここに } サブポリゴンの機能は、全体※が別の多角形に切り取られる文字"P"のような複雑な形状を生成するのに用いることができる。(※訳注:原文はwholeだがhole:"穴"であろう）: #declare P = polygon { 12, <0, 0>, <0, 6>, <4, 6>, <4, 3>, <1, 3>, <1, 0>, <0, 0>, <1, 4>, <1, 5>, <3, 5>, <3, 4>, <1, 4> } 最初のサブポリゴン(１番目の行)は文字"P"の外形を記述する。2番目のサブポリゴンは(2番目の行)は文字"P"の文字の上部に切りとられる長方形の穴を記述する。両長方形は閉じている。つまり最初の点と最後の点が等しい。 ポリゴンに穴を切り取る機能は、用いられたポリゴンの内側/外側のテストに基づく物である。ある点は、もしその点から任意の方向に引いた直線が奇数個の辺と交差する場合、ポリゴンの内部と判断される(これはジョルダンの曲線理論(Jordan's curve theorem)として知られている)。 以下に別の複雑な例として三つの小さな穴のある一つの大きな三角形、三つの分かれた小さな三角形を示す: polygon { 28, <0, 0> <1, 0> <0, 1> <0, 0> // 大きな外側の三角形 <.3,.7> <.4,.7> <.3,.8> <.3,.7> // 小さな外側の三角形 #1 <.5,.5> <.6,.5> <.5,.6> <.5,.5> // 小さな外側の三角形 #2 <.7,.3> <.8,.3> <.7,.4> <.7,.3> // 小さな外側の三角形 #3 <.5,.2> <.6,.2> <.5,.3> <.5,.2> // 内部の三角形 #1 <.2,.5> <.3,.5> <.2,.6> <.2,.5> // 内部の三角形 #2 <.1,.1> <.2,.1> <.1,.2> <.1,.1> // 内部の三角形 #3 } 7.5.3.5 三角形および平滑三角形(スムーズトライアングル) (図 三角形) 三角形プリミティブは組み込み形状で許されるものより複雑なオブジェクトを作るために提供されている。三角形は普通手で作らずに、他のファイルから変換するか、またはユーティリティによって生成される。三角形は、 triangle { <角1>, <角2>, <角3> } と定義される。 <角n>のところは、三角形の各頂点の x, y, z座標を定義するベクトルです。三角形は完全な平面なので、なめらかな曲面を近似するためには非常に多くの大変小さな三角形が必要になります。しかし、私達のなめらかな面の知覚の多くは、光や影が作られる方法に依存する。人工的に表面法線を変更することで、なめらかな表面をシミュレートし、三角形の間の縁の尖ったつなぎ目を隠すことができる。 平滑三角形プリミティブはそういう目的で使われる。平滑三角形はフォン法線補間法と呼ばれる、ユーザが三点で定義した法線ベクトルに基づく三角形の各点で表面法線を計算する公式を使います。これは三角形をなめらかな曲面に見せる。平滑三角形は、 smooth_triangle { <角1>, <法線1>, <角2>, <法線2>, <角3>, <法線3> } と定義される。普通の三角形の各点が定義されていて、<法線n>は表面法線の方向を指示するベクトルです。 法線ベクトルを手で計算するのはひどく困難です。だから、平滑三角形はほとんど常にユーティリティプログラムによって生成されます。なめらかな結果を得るには、頂点を共有するどの三角形も頂点において同じ法線ベクトルをもっていなければなりません。一般になめらかに処理された法線は、点を共有する三角形の、すべての実際の法線の平均でなくてはなりません。 7.5.4 無限ソリッドプリミティブ おそらく無限で、自動バウンディングに応答しないものとして、5種類の多項式プリミティブ形状があります。平面(plane)、三次曲面(cubic)、多次曲面(poly)、二次曲面(quadric)、四次曲面(quartic)の五つです。これらは、うまく定義された内部を持ち、CSGとclipped_by構文の内部で使える。すべての形と同じく、これらは移動、回転、拡大縮小ができる。 7.5.4.1 平面(plane) 平面プリミティブには無限の平らな面を定義する簡単な方法です。平面は以下のように指定される。 plane { <法線>, 距離 } <法線>ベクトルは平面の表面法線を定義する。表面法線はその表面から 90度の角度で立ち上がるベクトルのことです。このベクトルのあとに原点から平面までの法線に沿った距離を与える浮動小数値が続きます。(これは、法線ベクトルが単位長を持つ場合のみ正しくなります。以下を参照) 例: plane { <0, 1, 0>, 4 } これは真っ直ぐ上が正の y方向に定義された平面です。平面は、原点から4単位離れている。ほとんどの平面は軸方向への表面法線ベクトルとともに定義されているので、たいていは x, y, z組み込みベクトル識別子を使って定義された平面を見ると思います。前述の例は、 plane { y, 4 } とも指定できる。平面は x方向、z方向に無限に延びていて、世界を効果的に二つに分ける。定義により、法線ベクトルは平面の外側を指すことになり、ベクトルと反対方向のどの点も内側になります。この内側／外側の区別は、平面が CSGや clipped_byで使われるときのみ重要になります。 平面は、一次多項方程式により定義されるため多項形と呼ばれる。以下の平面を与えると、 plane { , D } 次のような方程式で表される。 A*x + B*y + C*z - D*sqrt(A^2 + B^2 + C^2) = 0. したがって、先ほどの例 plane {y,4 } は、実際は多項方程式 y=4 になります。これは、x, z値にかかわらず、すべて y値が 4に等しい x, y, z点の組と考えることができる。 それぞれの項は、x, y, z一次の冪(べき)数しかないので、この方程式は、一次多項式です。二次方程式は、x^2, y^2, z^2, xy, xz, yz の項を持ちます。二次方程式の別名は、二次(quadric)式です。三次多項式は、三次(cubic)式と呼ばれる。四次方程式は、四次式(qsuartic)です。これらの形は以下のセクションで述べられている。 7.5.4.2 多項式(Poly)、三次式(Cubic)、四次式(Quartic) (図 四次曲面(quartic cylinder)) 高次の多項式による面は、多項式(poly)形で定義される。シンタックス(構文)は、 poly { 次数, } 次数には、方程式の次数を指定する 2から 7の数が含まれる。T1, T2,... Tm は、方程式の係数としての浮動小数値群です。そのような項がm個あり、mは以下のように決まっている。 m = ((次数+1)*(次数+2)*(次数+3))/6. 三次の多項式を指定するもう一つの方法は、 cubic { } です。四次方程式は quartic { } となります。興味を持った人のために、四次式(quartic)は代わりにもっと数学的な記述ができる。quartic面は四次の面で、トーラス(ドーナツ型)やレムニスケート(連珠型) などを含む形の大きなクラスを記述することに使える。三つの変数を持つ四次方程式(quartic)の一般方程式(帽子にでも書き止めておいて下さい)は、 a00 x^4 + a01 x^3 y + a02 x^3 z+ a03 x^3 + a04 x^2 y^2+ a05 x^2 y z+ a06 x^2 y + a07 x^2 z^2+a08 x^2 z+a09 x^2+ a10 x y^3+a11 x y^2 z+ a12 x y^2+a13 x y z^2+a14 x y z+ a15 x y + a16 x z^3 + a17 x z^2 + a18 x z + a19 x+ a20 y^4 + a21 y^3 z + a22 y^3+ a23 y^2 z^2 +a24 y^2 z+ a25 y^2 + a26 y z^3 + a27 y z^2 + a28 y z + a29 y+ a30 z^4 + a31 z^3 + a32 z^2 + a33 z + a34 = 0 四次表面を定義するには、それぞれの係数(a0..a34)を順に置いた35項の単一の長いベクトルが必要となります。 例として、トーラスを難しいやり方で定義してみましょう。トーラスは、以下の方程式で表すことができる。 x^4 + y^4 + z^4 + 2 x^2 y^2 + 2 x^2 z^2 + 2 y^2 z^2 - 2 (r_0^2 + r_1^2) x^2 + 2 (r_0^2 - r_1^2) y^2 - 2 (r_0^2 + r_1^2) z^2 + (r_0^2 - r_1^2)^2 = 0 ここでr_0がトーラスの主半径で、ドーナツの穴からドーナツリングの真ん中までの距離で、r_1がトーラスの副半径であり、ドーナツリングの真ん中から、外側の表面までの距離です。次に挙げたのは、主半径 6.3、副半径が 3.5(最大幅はちょうど 20)のトーラスのオブジェクト定義です。 // 主半径 sqrt(40), 副半径 sqrt(12) のトーラス quartic { < 1, 0, 0, 0, 2, 0, 0, 2, 0, -104, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 2, 0, 56, 0, 0, 0, 0, 1, 0, -104, 0, 784 > sturm bounded_by { // bounded_byはレンダリングをスピードアップする、 // 詳しくは、ドキュメント中の // この後で説明されている // bounded_byを参照のこと sphere { <0, 0, 0>, 10 } } } ※訳者注 sqrtは、根号(square root)の意味です。 多項、三次、四次は、それを使うためにはそれを理解する必要がない二次式のようなものです。ファイル shapesq.incには、たくさんの四次式(quartic)があらかじめ定義されている。既定義の quarticを使うシンタックスは、こうなります。 object { Quartic_Name } 多項式は非常に複雑な計算をするが、いつも完全にレンダリングするとは限りません。表面がなめらかでなかったり、抜けや、極端に外れたピクセルがあるときは、定義の中にオプションのキーワード sturmを入れてみて下さい。計算は遅くなりますが、より正確な計算方法が用いられるようになります。常にとは言えませんが、普通これで問題が解決する。sturmが働かない場合は、物体を少しだけ回転させるか平行移動させてみて下さい。シーンにおける多項式の例は、シーンファイルのディレクトリ(povscn)の中のサブディレクトリ mathを参照して下さい。 実際たくさんの異なる quartic 形があるので、そのすべてをここに羅列して説明はできません。興味があり、数学的に知りたいのなら、quartic形の公式が書かれた優れた参考書として、以下のものがあります。 "The CRC Handbook of Mathematical Curves and Surfaces" David von Seggern CRC Press, 1990 7.5.4.3 二次曲面(quadric) (図 二次曲面(paraboloid:放物面)) 二次曲面は楕円体面、球面、円錐、円筒、放物面(お皿の形)、双曲面(鞍、砂時計の形)を作ることができます。QuaDRicとQuaRTicを混同しないよう注意して下さい。quadricは二次多項式で、quarticは四次多項式です。quadricはより速く、よりエラーが少ないレンダリングになります。 quadricは POV-Rayでは、次のように定義されている。 quadric { , , , J } A から J は浮動小数点式で、次の方程式を満たす x, y, zの面を定義する。 A x^2 + B y^2 + C z^2 + D xy + E xz + F yz + G x + H y + I z + J = 0 A, B, C,... Jの値を変えれば、異なった形となります。三次元上の一点がオブジェクトの表面に乗っていれば、その点の x, y, z座標を上の方程式に代入した値が 0 になります。点が物体の内側にあれば負の値、外側にあれば正の値になります。幾つか例を挙げる: X^2 + Y^2 + Z^2 - 1 = 0 球 X^2 + Y^2 - 1 = 0 Z軸に沿った無限の円筒 X^2 + Y^2 - Z^2 = 0 Z軸に沿った無限のコーン これらの形を一番簡単に使うには、標準ファイル shapes.incをプログラムにincludeすれば良いのです。このファイルにはあらかじめ定義された二次曲面がいくつも含まれており、そういう既定義の形を(移動、回転、拡大縮小を使って)好きなように変形できる。シンタックスは次のようになります。 object { Quadric_Name } 既定義の二次曲面は、原点 <0,0,0>が中心になっており、半径 1 です。半径を幅と混同しないで下さい。半径は直径あるいは幅の半分で、標準二次曲面の幅は 2単位です。 既定義の二次曲面(quadrics)のいくつかを以下に挙げておきます。 Ellipsoid(楕円体) Cylinder_X, Cylinder_Y, Cylinder_Z(円筒) QCone_X, QCone_Y, QCone_Z(コーン) Paraboloid_X, Paraboloid_Y, Paraboloid_Z(放物面) 7.5.5 構成的立体幾何(CSG) POV-Rayは、構成的立体幾何(CSG)をサポートし、五つの異なる操作:差(difference)、交差(intersection)、併合(merge)、結合(union)、否定(nagation)または反転(negation、inversion)があります。始めの四つの操作は二成分(binary)の演算子、つまり二つの引数が必要であるのに対し、否定は一成分(unary)の演算子で、引数は一つだけです。 7.5.5.1 CSGについて 構成的立体幾何は、二つもしくはそれ以上のオブジェクトを組み合わせ、結合、交差、否定の三つの論理セットを使って新しいオブジェクトを作成するテクニックです。これは、ソリッドオブジェクトすなわち正しく定義された内側のあるオブジェクトに対してだけ働きます。これは、有限ソリッドプリミティブと無限ソリッドプリミティブの章で述べたすべてのオブジェクトが含まれる。 CSG形は標準形状が使われるどんな場合に使ってもよく、CSG形の中でもかまいません。CSG形には、移動、回転、拡大縮小が他の形と同様に作用する。CSG形を構成する形は個々に移動、回転、拡大縮小される。 7.5.5.2 内側と外側 球、ボックス、ブロブのような、ほとんどのプリミティブは、世界を二つの領域に分ける。その一つはオブジェクトの内側、一つは外側です。 空間に与えられたどの点も、すべてのプリミティブオブジェクトの内側にあるか、外側にあるかを決めることができる。そう、表面に正確に乗っていてもです。その場合数の精度の問題でやや決定し難くはありますが。 平面でさえ内側と外側があります。定義上、平面の表面法線は、平面の外側を指します。三角形や三角形から作られた形は、空間で内側と外側が正しく定義されていないため、CSGではソリッドオブジェクトとしては使えません。 CSGには、以降の章で説明されているように、形を組み合わせるために内側と外側の概念があります。 下の図で示されている部分的に重なったオブジェクトが必要だと考えてみて下さい。四つの異なった領域が区別できる。すなわち、ある点はオブジェクト Aと Bの外か、Aの中で Bの外か、Aの外で Bの中か、Aと B両方の中という四つです。 * = オブジェクト A % = オブジェクト B * * * % * * % % * *% % * %* % * % * % * % * % *******%******* % % % %%%%%%%%%%%%%%%%% 図 二つの重なったオブジェクト これを心に止めておけば、CSG操作がどのように働くかを理解するのは極めて容易です。 7.5.5.3 反転(inverse) CSGを使うとき、オブジェクトを反転させると内側外側を裏返しにできるので便利です。オブジェクトの外見は変わらず、POV-Rayの認識の仕方が変わるだけです。キーワード inverseが使われると、ひっくり返されて形の内側が外側に変わります。 差(difference)の操作では、片方のオブジェクトともう片方のオブジェクトの反転との交差(intersection)で行われることにも留意して下さい。 7.5.5.4 結合(Union:ユニオン) * * * % * * % % * *% % * %* % * % * % * % * % *******%******* % % % %%%%%%%%%%%%%%%%% 図 二つのオブジェクトの結合 (図 ボックスと円筒の結合) 結合(union、ユニオン、和)は単に二つまたはそれ以上の形を一つのオブジェクトとして扱われるように一つの実体に合わせるための接着剤です。上の絵は A と B の結合を表している。結合操作によって生成された新しいオブジェクトは拡大縮小、移動、回転が単一のオブジェクトと同様にできる。結合の中のそれぞれのオブジェクトは自分自身のテキスチャを持っていてもよいのですが、結合全体は一つのテキスチャを共有することができ、それは親のオブジェクトのテキスチャ行を上書きする。 結合の内側の面は除かれないことを知っておく必要があります。絵からわかるように、これは透明な結合体にとって問題となります。もし、そういう面を除きたければ、後の章で述べられている併合操作を使わなければなりません。 次の結合(union)は、ボックスと球を含むものです union { box { <-1.5, -1, -1>, <0.5, 1, 1> } cylinder { <0.5, 0, -1>, <0.5, 0, 1>, 1 } } 旧バージョンの POV-Rayでは、結合(union)に制限があり、オブジェクトを組み合わせるためにはしばしば composite行の記述をしなければなりませんでした。現バージョンではそのような制限は取り除かれています。compositeは、互換性保持のためにサポートされていますが、将来にわたってcompositeキーワードがサポートされる保証はありません。 7.5.5.5 交差(intersection、積) 点がオブジェクト A と B の両方の内側にあれば、その点は交差の中にあり、以下の図で示される。 %* % * % * %******* 図 二つのオブジェクトの交差 (図 ボックスと円筒の交差) 例: intersection { box { <-1.5, -1, -1>, <0.5, 1, 1> } cylinder { <0.5, 0, -1>, <0.5, 0, 1>, 1 } } 7.5.5.6 差(difference) CSGにおける差の操作は一番目のオブジェクトと、二番目のオブジェクトの反転との交差になります。つまり、オブジェクト A の内側で、オブジェクト B の外側にある点だけが両オブジェクトの差に属します。 結果は、二番目のかたちから一番目の形を差し引いたようになり、以下の図で示される。 * * * * * * * * 1 % * % * % *******% 図 二つのオブジェクトの差 (図 円筒がボックスから差し引かれた。) 例: difference { box { <-1.5, -1, -1>, <0.5, 1, 1> } cylinder { <0.5, 0, -1>, <0.5, 0, 1>, 1 } } 7.5.5.7 併合(merge:マージ) 結合(union)操作※は、オブジェクト同士を単にくっつけるだけですが、結合の内側のオブジェクトの面は取り除きません。透明な結合体が使われると、その面が可視となります。 （※訳注:unionを「和」とし、mergeを「結合」と呼ぶ場合もある。） 併合操作はこの問題を避けるために使うことができる。併合は結合のように働きますが、下図で示したように内部の面が削り落される。 * * * % * * % % * *% % * % * % * % *******% % % % %%%%%%%%%%%%%%%%% 図 併合は内部の面を取り除く。 (図 内部の表面を見せている透明な結合) (図 内部の面のない透明な併合) 7.5.6 光源(Light Sources) 最後にカバーするオブジェクトは光源(light source)である。光源は、それ自身は見える形状を持たない。それらは光を放射する点あるいは面でしかない。それらの完全な構文は: light_source { <位置> color <色> [ spotlight ] [ point_at <参照点> ] [ radius 半径 ] [ falloff 減退 ] [ tightness タイトネス ] [ area_light <軸1>, <軸2>, サイズ1, サイズ2 ] [ adaptive 適合 ] [ jitter ジッタ ] [ looks_like { オブジェクト } ] [ fade_distance フェイド距離 ] [ fade_power フェイド指数 ] [ atmospheric_attenuation ブール ] } それぞれのタイプの光源とオプションの修飾子について以下のセクションで詳しく述べる。 7.5.6.1 点光(Point Lights) 点光源(point light source)はすべての方向に指定した色の光を放つ。その位置はlocationキーワードによって記述され、その色はcolorキーワードによって与えられる。完全な構文は: light_source { <位置> color <色> [ looks_like { オブジェクト } ] [ fade_distance フェイド距離 ] [ fade_power フェイド指数 ] [ atmospheric_attenuation ブール ] } 7.5.6.2 スポットライト(Spotlights) スポットライト(spotlight)は光の光線が円錐形に拘束される点光源である。その光は、この円錐形の中央で明るくて、円錐形のふちで明るさが落ちる(falls off)か、暗くなる。構文は: light_source { <位置> color <色> spotlight point_at <参照点> radius 半径 falloff 減退 tightness タイトネス [ looks_like { オブジェクト } ] [ fade_distance フェイド距離 ] [ fade_power フェイド指数 ] [ atmospheric_attenuation ブール ] } スポットライトは、spotlightキーワードによって識別される。それは"位置"に位置し"参照点"を指す。以下の図はそれらの値が互いにどのように関係するかの理解の助けになるだろう。 (+) location(位置) / \ / \ / \ / \ / \ / \ +-----*------+ ^ point_at(参照点) 図 スポットライトの幾何。 (図 スポットライトの中心(center)と参照点(point_at)) スポットライトの他のパラメータは、半径(radius)、減退(falloff:フォールオフ) およびタイトネス(tightness:堅固)である。 スポットライトを図に示したような2つの入れ子になった円錐と考えよう。内側の円錐は半径パラメータによって指定され、それは完全に照らされる。外側の円錐は減退円錐で、その外側には光は無い。これらの二つのパラメータに対する値は開いている角度の半分であり、両方の角度は90度よりも小さくなければならない。以下の図でしめすように半径と減退角度の間で光は滑らかに減退する(半径角度が負でない限り)。 図 45度に固定された減退角度をもつ強度乗数曲線(Intensity multiplier curve)。 図 45度に固定された半径角度をもつ強度乗数曲線 タイトネス(tightness)値は光がスポットライトの中心線から減退円錐(その外側は完全に暗い)までどれくらい速く薄暗くなるか、あるいは減退するかを指定する。タイトネスのデフォルト値は10である。低いタイトネス値はスポットライトをより明るくし、スポットをより広くし、エッジをより鋭くする。より高い値はスポットライトを暗くし、スポットをよりタイト(きつく)にし、エッジをよりソフトにする。1 から 100 までの値が許される。 図 固定角度で減退角度がそれぞれ30度と60度で異なるタイトネス値の強度乗数曲線。 図から、半径と減退角度がタイトネスパラメータと影響し合うことにあなたは気がつくはずである。以下の図から分かるように、半径角度が負の場合だけ、タイトネス値にスポットライトの外観の完全な制御を与える。減退角度が無効の場合、照らされる領域はタイトネスパラメータだけで決められる。 図 負の半径角度と様々なタイトネス値での強度乗数曲線 スポットライトは通常の光源が使える場所ならどんな場所でも使用できる。いずれの光源とも同様にこれらは見えない。これらは形状(shapes)として扱われ、CSG形状に含まれても良い。これらはまた、エリア光とともに使ってもよい。 7.5.6.3 円筒状光(Cylindrical Lights) 円筒状光源は光の光線が円錐ではなく円筒で拘束されることを除き、スポットライトと非常に良く似た働きをする。その構文は: light_source { <位置> color <色> cylinder point_at <参照点> radius 半径 falloff 減退 tightness タイトネス [ looks_like { オブジェクト } ] [ fade_distance フェイド距離 ] [ fade_power フェイド指数 ] [ atmospheric_attenuation ブール ] } radius、falloffおよびtightnessキーワードはスポットライトのときと同じ機能を制御する。 円筒光源はまだ点光源であることを心にとどめておかなければならない。光線は一点から放射され、円筒で拘束されるだけである。光の光線は平行ではない。 (訳注:pov3demo\lights\cyllite1.pov参照) 7.5.6.4 エリア光(Area Lights) エリア光源(Area light sources、面光源)は１次元あるいは２次元の有限な領域を占める。それらは部分的に光を妨げることができるため、柔らかな影を投げかけることができる。 POV-Rayで用いられるエリア光は形状が長方形で、平らなパネル光の一種のようなものである。実際のエリア光をモデル化するために要求される複雑な計算を実行するかわりに、それはそのライトで占められた領域の上に並べられた点光源の配列で近似される。配列の中のそれぞれの点光の強度は薄暗くなる。そのためそのライトから放射される光の総量は宣言の中で指定した光の色に等しい。構文は: light_source { <位置> color <色> area_light <軸1>, <軸2>, サイズ1, サイズ2 adaptive 適合 jitter ジッタ [ spotlight ] [ point_at <参照点> ] [ radius 半径 ] [ falloff 減退 ] [ tightness タイトネス ] [ looks_like { オブジェクト } ] [ fade_distance フェイド距離 ] [ fade_power フェイド指数 ] [ atmosphere ブール ] [ atmospheric_attenuation ブール ] } このライトの位置(location)と色(color)は通常の光源と同じように指定される。 area_lightコマンドはその光源配列の中のライトの数と共にエリア光の大きさと向きを定義する。ベクトル"軸1"および"軸2"はライトの辺の長さと方向を指定する。エリア光は空間内の長方形であるから、これらのベクトルは互いに直交していなければならない。ライトの大きさが大きいほど、影のソフトな部分がより太くなる。"サイズ1"と"サイズ2"の数は点光の配列の寸法を指定する。より多くのライトの使用はよりスムーズな影になるが、レンダリングにかかる時間はより長くなる。 jitterコマンドは選択可能である。それが使われた場合、影が帯状になるのを防ぐために配列の中の点光の配置がランダムにジッタ(踊ら)される。このジッタリングはレンダリングからレンダリングへ完全にランダムになされるためアニメーションの生成には使うべきでない。 注意:エリア・スポットライトを作成するためにspotlightパラメータをarea_lightパラメータと共に指定することができる。長ったらしい柔らかな影の計算を、それが必要なシーンの部分だけに制限することができるので、エリア光を用いたシーンのスピードアップのためにエリアスポットライトを用いることは良い方法である。 直線型の光源を用いて面白い効果を作成することができる。長方形の形状を持つというよりむしろ直線型であるライトは、細い蛍光管の一種のように直線に沿って伸びる。直線型のライトを作成するためには、配列の1つの寸法が1にセットされたエリア光を作成するだけである。 adaptiveコマンドは光源の適合サンプリングを可能にするために用いられる。デフォルトでPOV-Rayは1つのエリア光からある表面に届く光の量を、配列内のすべての点光にテスト光線を投げかけ計算する。想像できるようにこれは非常に遅い。一方、適合サンプリングは、最小数のテスト光線を用いて同じ計算を近似することを試みる。このキーワードの後ろに指定される値はどのくらい多くの適合サンプリングを使うかを制御する。その数が大きいと影はより正確になるがレンダリングにかかる時間はより長くなる。もし、どんな値を使えば良いのかはっきり分からない場合、良い出発点は adaptive 1である。adaptiveキーワードは整数値だけを受け入れ、0より小さな値は設定できない。 適合サンプリングを実行する時、POV-Rayはエリア光の４角の点にテスト光線を発射することから始める。もし、４角全部から受け取る光の量が近似的に等しければ、エリア光は完全に見えるか、完全にブロックされているかのどちらかだと仮定される。光の強度は4角(すみ)から受け取った光の強度の平均として計算される。 しかしながら、もし4角からの光の強度が十分に異なる場合は、そのエリア光は部分的にブロックされている。そのエリア光は４分の1に分割され、それぞれの部分が上で述べたようにサンプルされる。これはPOV-Rayが、配列内のすべてのライトにテスト光線を発射することなしに、どのくらい多くのエリア光が見えるかを、す速く近似することを可能にする。視覚的には、サンプリングは以下に示すように進む。 レベル 0 1 2 3 光線 4 9 25 81 *...* x.*.x x * x * x .....　 　..... * * * * * ..... *.*.* x * x * x など... ..... 　　..... * * * * * *...* x.*.x x * x * x * 新しいサンプル x 前のレベルから再利用されるサンプル 図()　エリア光の適合サンプル。 適合サンプリング法は高速であるが(相対的な話である)、ときどき不正確な影を作り出す。その解決案は、完全にそれをoffにすることなく適合サンプリングの量を減らすことである。adaptiveキーワードの後ろの数値は、適合段階に入る前に、エリア光が分割される回数を調整する。例えば、もしあなたがadaptive 0 を使う場合、最小の4光線がライトに放たれるであろう。もしあなたがadaptive 1 を使うと、最小9つの光線が放たれるであろう( adaptive 2 は 25 の光線、adaptive 3 は 81の光線、などを与える)。明らかに、あなたがより多くの影光線(shadow rays)を放つと、レンダリングはより遅くなる。したがってあなたは、満足な結果が得られる最小の値を使うべきである。 光線の数はあなたが行と列で指定した点の値を決して越えることはない。例えばarea_light x,y,4,4 は4×4配列のライトを指定する。もしあなたがadaptive 3を指定すると、それは9×9の配列から始めることを意味する。この場合、適合サンプリングはなされない。4×4の配列が使われる。 7.5.6.5 影を作らない光(Shadowless Lights) shadowlessキーワードを用いて、光源が影を投げかけるのをやめさせられる。 (訳注:pov3demo\lights\filllite.pov参照) 7.5.6.6 Looks_like(〜のように見える) 通常、光源それ自身は見える形を持たない。ライトは見えない点や面から単純に光を放射するだけである。あなたは、looks_like {オブジェクト}構文を追加することにより、光源に任意の形状を与えることができる。 looks_likeのオブジェクトには暗黙のno_shadowが付けられているので、ライトはそのオブジェクトにより遮(さえぎ)られることはない。この自動的なno_shadowなしでは、オブジェクト内部の光は外へ逃げられない。要するに、オブジェクトは、すべてに影を投げかける。 もしあなたが、その(ライトに)結びついているオブジェクトに光を遮って欲しいのなら、あなたは以下のようにlooks_likeでなく、結合(union:ユニオン)でそれを結びつけるべきである。 union { light_source { <100, 200, -300> color White } object { My_Lamp_Shape } } 7.5.6.7 ライトフェイディング(Light Fading) デフォルトでPOV-Rayはいかなる光源の光も、それが空間を通って移動するにつれて減少させることはない。より現実的な効果を得るために、距離に基づく光の強度(intensity)の減退(foll off:フォールオフ)をモデル化するためにfade_distance(フェイド距離)およびfade_power(フェイド指数)を使うことができる。 fade_distanceキーワードは完全な強度の光が届く距離を指定するために使われる。つまりcolorキーワードで与えられた強度である。実際の減衰(attenuation)は、減退率を決めるfade_powerキーワードによって記述される。つまり、"フェイド指数"をそれぞれ1あるいは2に設定することにより、線形あるいは2次式の減退を使うことができる。光を減衰させる係数を計算するための正確な公式は 2 減衰 = ------------------------------------- 1 + (d / フェイド距離) ^ フェイド指数 ここでdは光が進行した距離である。 図 様々なフェイド指数に対するライトフェイディング あなたは、2つの重要な事実に注意するべきである：第１に"フェイド距離"が１より大きい場合、"フェイド距離"よりも距離が小さい時の光の強度は実際に増加する。これは距離が"フェイド距離"に等しい場合に光源の色を得るために必要である。第２に光源から直接来る光だけが減衰させられる。反射あるいは屈折した光は距離による減衰はしない。 7.5.6.8 大気との相互作用(Atmosphere Interaction) デフォルトで、光源はシーンに付け加えられた大気と影響し合うだろう。この動作は光源構文(light source statement)の中でatmosphereキーワードを用いることによってoffに切り換えることができる。 light_source { ... atmosphere off } 7.5.6.9 大気による減衰(Atmospheric Attenuation) 通常、光源から来る光はフォグや大気に影響されない。これは特定の光源に対する大気による減衰(atmospheric attenuation)をonに切り換えることにより変更できる。この光源から来るすべての光は、フォグや大気の中を通って進むにつれ今度は減少する。これは使われたフォグや大気によって決定される距離に基づく指数関数的な強度の減退になる。フォグも大気も無い場合は何の変化も見られない。 7.5.7 オブジェクト修飾子(Object Modifiers) いろいろな修飾子がオブジェクトに付けられても良い。平行移動、回転および拡大縮小のような変換はすでに論じた。テクスチャは以降のそれ自身のセクションにある。ここには他の重要な3つの修飾子がある:clipped_by, bounded_by および no_shadowである。以下の例ではオブジェクト構文とオブジェクト識別子を使うけれども、これらの修飾子は球、ボックス、などのような任意のタイプのオブジェクトに使うことができる。 7.5.7.1 Clipped_By(切り取られる) clipped_by構文は技術的にはオブジェクト修飾子であるが、それはCSG交差と同様なある種のCSGを提供する。あなたは以下ようにクリッピング(切り抜き)オブジェクト(clipping object)を付ける: object { My_Thing clipped_by{plane{y,0}} } この平面(plane)の内側のオブジェクトMy_Thingのすべての部分は保持されるが、残りの部分は切り取られ捨てられる。(CSG)交差オブジェクトでは穴は閉じられ、なくなる。clipped_byでは穴を残す。例えば、以下の図はオブジェクトAがオブジェクトBで切り取られて(clipped by)いるのを示す。 * * * * * * *************** 図　あるオブジェクトが他のオブジェクトで切り取られた(clipped by)。 (図 ボックスで切り取られた円筒) clipped_byは、任意の形の一部分を切り取るために使われてもよい。多くの場合、またそれは形を変える他の方法より速いレンダリング時間になるだろう。 しばしばあなたは同じオブジェクトにclipped_byおよびbounded_byオプションを使いたくなるだろう。以下のショートカット(近道)はタイピングを節約し、より少ないメモリーを使う。 object { My_Thing bounded_by { box { <0,0,0>, <1,1,1> } } clipped_by { bounded_by } } 7.5.7.2 Bounded_By(境界づけられる) 光線がオブジェクトをヒットするかどうか調べるために必要な計算にはとても時間がかかる。各々の光線はシーンの中のあらゆるオブジェクトに対してテストされなければならない。POV-Rayはそこで、オブジェクトを一緒に集め、一そろいのバウンディングボックス(bounding boxes)と呼ばれる見えないボックスを造り、処理のスピードアップを試みる。この方法では、シーンの一部分を移動する光線はシーンの遠く離れた他の部分のオブジェクトに対してテストされる必要がない。非常にたくさんのオブジェクトが存在する場合、このボックスは互いの内部に入れ子になる。POV-Rayは任意の有限オブジェクト、そしていくつかの切り取られた(clipped)あるいはバウンディング(bounded)された2次曲面(quadrics)にバウンディングボックスを使うことができる。しかしながら、(平面(planes)、4次多項式(quartic)、3次式(cubic)および多項式(poly)のような)無限オブジェクトは自動的なバウンディングはできない。CSGオブジェクトは、もしそれが有限オブジェクト(およびいくつかの場合無限でも)を含む場合、自動的にバウンディングされる。これはCSGオブジェクト内部で用いられているすべてのオブジェクトのバウンディングボックスへのCSG集合(set)演算の適用によって働く。差(difference)および交差(intersection)演算に対しては、これは最適なバウンディングボックスにはめったに至らないだろう。そのような形に対してはbounded_by構文を用いることが(CSGオブジェクトの複雑さに依存するが)より良いこともある。 通常、バウンディング形状(bounding shapes)は必要ではないが、複雑なオブジェクトのレンダリングをスピードアップするために使うことができる場合がある。バウンディング形状はそのオブジェクトが単純な形状によりすっかり囲まれていることをレイトレーサーに知らせる。光線のトレーシング時、その光線は単純なバウンディング形状に対して最初にテストされる。もし、その光線がバウンディング形状にぶつかった場合、その光線は内部のより複雑なオブジェクトに対してさらにテストされる。そうでなければ、複雑な形全体がスキップされ、大いにレンダリング速度を高める。 バウンディング形状を使うためには、単にあなたのオブジェクトの宣言に以下の行を含めなさい: bounded_by { object {... } } バウンディング形状の例: intersection { sphere { <0,0,0>, 2 } plane { <0,1,0>, 0 } plane { <1,0,0>, 0 } bounded_by { sphere { <0,0,0>, 2 } } } 最も良いバウンディング形状は高度に最適化されている球あるいはボックスであるが、任意の形状が使える。もしバウンディング形状がそれ自身バウンディングスラブ(bounding slabs:平板?)に応答する有限形状であれば、それが囲むオブジェクトはまたそのスラブシステム(slab system)の中で使われるだろう。 CSG形状は、bounded_by構文無しでバウンディングスラブから利益を受けることができるが、それらは交差(intersection)、差(difference)および併合(merge)の中ではとても無効果にするかもしれない。これら3つのCSGタイプでは用いられた自動バウンド(bound)はそれら全体の構成要素オブジェクトのすべてをおおう。しかしながら、これらの交差(intersections)の結果はより小さいオブジェクトになるかも知れない。結合と交差のために、上のCSGセクションの中の図の大きさを比較しなさい。自動バウンドは指定されたCSGによらず、AとＢの結合(union)の大きさであるが、AとBの交差(intersection)のまわりにAとBの結合より小さいボックスを描くことは可能である。 手動でbounded_byを交差(intersection)、差(difference)および併合(merge)につけ加えることは大抵の場合良い考えであるが、結合(union)にはバウンドしないのが多くの場合ベストである。もし結合(union)にbounded_byもclipped_byも無い場合、POV-Rayはunionの構成要素を内部的に別々に分解し、その有限部分に自動バウンディングスラブを適用することができる。raw2povのようないくつかのユーティリティでは現時点のPOV-Rayのシステムよりもより効果的にバウンドを生成することがあるということに注意しなさい。しかしながら、あなた自身が作るほとんどの結合(unions)は簡単に自動システムによりバウンドされる。技術的理由によりPOV-Rayは併合(merge)オブジェクトを分解できない。たぶん併合は手でバウンドするのがベストであろう。特にもしそれが非常に複雑な場合は。 注意：もしバウンディング形状が小さすぎたり、間違って置かれた場合、それは不確定な方法でオブジェクトを切り取ったりあるいはそのオブジェクトが全く現れなくなったりするかもしれない。正確なクリッピングをするために上で説明したclipped_byを使いなさい。しばしばあなたはclipped_by および bounded_byオプションを同じオブジェクトに使いたくなるだろう。以下のショートカットはタイピングを節約し、より少こしのメモリーを使う。 object { My_Thing clipped_by{ box { <0,0,0>,<1,1,1 > }} bounded_by{ clipped_by } } 7.5.7.3 Hollow(中空) デフォルトでPOV-Rayは、オブジェクトはその内部を完全に満たす固体材料(solid material)でできていると仮定する。オブジェクトにhollowキーワードを加えることにより、それを中空(hollow)にすることができる。これはあなたがオブジェクト内部に大気の効果を存在させたい場合に非常に便利である。これはハローを含むオブジェクトにも要求される(詳しくは"ハロー"を見て下さい)。 中空のCSGオブジェクトを得るためには、あなたは最上位のオブジェクトを中空にしなければならないだけである。すべての子供たち(children)はその状態が明示的に指定された場合を除き、(親と)同じ中空状態と仮定される。以下の例では結合(union)内部の2つの球両方が中空(hollow)にセットされる union { sphere { -0.5*x, 1 } sphere { 0.5*x, 1 } hollow } 一方、次の例は最初の球が明示的に中空では無いように設定されているので、２番目の球だけが中空にセットされる。 union { sphere { -0.5*x, 1 hollow off } sphere { 0.5*x, 1 } hollow } 7.5.7.4 No_Shadow(影無し) あなたはオブジェクトが影を投げかけなくなるようにするためにno_shadowキーワードをオブジェクトに指定することができる。これは、特殊な効果のために、そして、光源が実際に見える錯覚(illusion)を作成するために役に立つ。このキーワードはlooks_like構文を持たなかった初期のバージョンのPOV-Rayのために必要であった。現在はレーザー光線や他の非現実的な効果を作成するために便利である。 単にキーワードを以下のように付加すればよい: object { My_Thing no_shadow } 7.5.7.5 ステュルム(Sturm) いくつかのPOV-Rayのオブジェクトでは高速だがときどき不正確な求根法と、より遅いがより正確な物との間で選択が可能である。これは、三次あるいは、4次多項式の解法を必要とするすべてのオブジェクトのためである。使われる可能性があるそれらの多項式のための解析的な数学的解法がある。 低次の多項式を解くことは取るに足らないことであるが、より高次の多項式ではそれを解くために反復アルゴリズムを必要とする。それらのアルゴリズムの一つがステュルムの求根法(Sturmian root solver)である。 以下のリストではすべてのステュルムの求根法が利用できるオブジェクトを示す。 ブロブ(blob) 三次式(cubic) レイズ(lathe) (２次スプラインのみ) 多項式(poly) プリズム(prism) (３次スプラインのみ) ４次式(quartic) 回転面(sor) 7.6 テクスチャ(Textures) 　 テクスチャ(texture)はオブシェクトがどのように見えるか、つまりその素材(material:マテリアル)を記述するものである。テクスチャはピグメント(pigment)や、法線(normal)や、仕上げ(finish)やハロー(halo)の組み合わせからなる。ピグメントは素材固有の色や、色のパターンの事である。法線は、表面の法線ベクトルを変化させることで、波(wave)やささ波(ripple)、くぼみ(dents)、凹凸(bump)のいろいろのパターンをシミュレートする手法の1つである。仕上げ(finishe)は、素材の屈折や反射の属性を記述する。ハローはオブジェクトの中で定義された密度フィールドを使うことによって雲や、霧や、炎のようなものの効果をシミュレートする。 プレイン(plain)テクスチャは、1つのピグメント、オプションの法線、1つの仕上げ、オプションの１つまたは、複数のハローから成り立っている。特殊(special)テクスチャは、パターンや、混合関数(blending function)を使った2つまたは、それ以上のテクスチャを組み合わせる。特殊テクスチャは、パターンの中にパターンをネスティングすることによって、とても複雑なものになるかもしれない。しかしながら、もっとも深いレベルの部分は、プレインテキスチャから構成されている。注意:プレインテクスチャをプレイン(質素な、単調な、無地の)と呼んでするが、それは、とても複雑なテクスチャである。プレインという用語は、それが１つのピグメント(pigment)、法線(normal)、仕上げ(finish)、ハローを持つことを意味しているにすぎない。 プレインテクスチャを定義するための最も完全な形式は、下記のようである: texture { "テクスチャ識別子" pigment {..}. normal {..}. finish {..}. halo {..}. "変換" } テクスチャのそれぞれの項目は、選択自由だが、もしそれが存在してるなら､識別子 は最初で"変換"は最後でなければならない。ピグメント(pigment)や、法線(normal)や 、仕上げ(finish)のパラメータは、"テクスチャ識別子"の中ですでに指定されているどんなピグメント(pigment)、法線(normal)、仕上げ(modify)パラメータも、変更する。また、すでに指定されているハローにも、あらゆるハローが加えられる。もし、"テクスチャ識別子"が指定されてなかったら、ピグメント(pigment)、法線(normal)、仕上げ(finish)構文は、現在のデフォルト値を変更し、また、どんなハローもデフォルトのハローに加えられる。"変換"は、平行移動(translate)、回転(rotate)、拡大縮小(scale)と、マトリックス(matrix)構文などの事である。それらは、最後に指定すべきである。 ピグメント(pigment)や、法線(normal)や、仕上げ(finsihe)やハローについての、指定可 能なオプションは下の章で述べている。特殊テクスチャについては後ほど、記述されて いる。 7.6.1 ピグメント(Pigment) オブジェクトの色や、色のパターンは、ピグメント(pigment)構文で定義される。プレインテクスチャはすべて、ピグメントをもっていなければならない。もし、ピグメントを指定していないのなら、デフォルトのピグメントが使われる。ピグメント構文はテクスチャの定義の1部分である。しかしながら、オブジェクトに色をつけるためだけにtexture {pigment {... }}と打ち込むのはながったらしい。そこでテクスチャの１部分として、明示的に定義しなくとも、オブジェクトに直接、ピグメントをはりつることもできる。: //これを... //このように短縮することが可能である... object { object { My_Object My_Object texture { pigment {color Red} pigment {color Red} } } } 定義した色はオブシェクトが完全に光で照らされた時にあなたの望むみばえの色になる。オブジェクトの本来の基本色を選べば、POV-Rayは、シーンの中のライティング次第で、明るくしたり暗くしたりする。このパラメーターがピグメント(pigment)と呼ばれるのは、基本色をオブジェクトの色がどのように「見える」かより、実際に「である」かを定義しているためである。 ピグメントを定義するためのすべてそろった形式は下記のとおりである: pigment { "ピグメント識別子" "パターンタイプ" "ピグメント修飾子"... } ピグメントのそれぞれの項目は選択自由だが、それらを定義するなら、期待した結果が得られるようにするために、上に示した順にするべきである。"ピグメント識別子"で与えられた設定は、その後の項目で上書きされるか修正される。もし、何の識別子も定義されていなかったら、項目は、現在のデフォルトの設定のテクスチャの中のピグメントの値を修正する。有効な"ピグメント修飾子"はtranslate(平行移動)、rotate(回転)、scale(拡大縮小)、turbulence(動乱)、wave shape(波の形状)や、warp(ゆがみ)構文のような一般的な"パターン修飾子"と同様に、color_map(カラーマップ)、pigment_map(ピグメントマップ)、image_map(イメージマップ)やquick_color(クイックカラー)構文などである。そのような、修飾子はピグメントにだけ適用され、テクスチャの他の部分には適用されない。修飾子は最後に指定するべきである。 それぞれのパターンのタイプは、おおよそ４つのカテゴリに分かれている。それぞれカテゴリは、下の章で述べられている。これらは単色(solid color)、カラーリストパターン (color list patterns)、カラーマップパターン(color mapped patterns)、イメー ジマップ(image maps)である。 7.6.1.1 単色ピグメント(Solid Color Pigments) もっとも簡単なタイプのピグメントは単色(solid color)である。単色を指定するためには、単にピグメントの中に色の指定を記述するだけでよい。例えば: pigment {color Orange} 色の指定はオプション(選択自由)のキーワードcolorに続く、色識別子あるいは赤、緑、青、フィルタのかかる透明度およびフィルタのかからない透明度の量によって構成される。色についての詳細は、"Specifying　Colors"を見て下さい。単色とともにつかわれるパターン修飾子は、修正するためのパターンがないため、無視される。 7.6.1.2 カラーリストピグメント(Color List Pigments) ３つのカラーリストパターン(color list pattern)がある。:チェッカー(checker)、ヘキサゴン(hexagon:六角形)とプリック(brick:煉瓦)である。結果としては、カラーマップパターンと同様に、色の混合というよりはむしろ、明瞭なふちを持つ単色パターンである。それらのパターンについての詳細は後の章に記述されている。それぞれの記述方法は次のようである: pigment { brick カラー1, カラー2 修飾子... } pigment { checker カラー1, カラー2 修飾子... } pigment { hexagon カラー1, カラー2, カラー3 修飾子... } それぞれのカラーnはすべて有効な色(color)の指定である。POV-Rayがそれぞれの色の指定の始めと終わりが何処かわかるようにするために、それぞれのcolorあるいはcolorキーワードの間にコンマをセパレートしておく。 7.6.1.3 カラーマップ(Color Maps) 多くのカラーパターンは、レンガ(brick)や、チェッカー(checker)、六角形(hexagon:ヘキサゴン)のパターンのような２色または、３色の急な色の変化は使わない。それらは、代わりに一点から次の点に徐々に変化してゆく、色がスムーズに移り変わる方法を使う。それらの色は、１つの色から次の色へと混ぜ合わせてゆく方法を記述しているカラーマップと呼ばれるピグメント修飾子のところで定義される。 利用可能ないろいろなパターンタイプのそれぞれは、実は任意のx、y、zの位置をとり、0.0と0.1を含むその間の数に変える数学的関数なのである。この数はカラーマップから使う色をどのように混ぜ合わせるかを指定するためにつかわれる。 カラーマップはこのように定義する... pigment{ "パターンタイプ" color_map { [ 数値_1 カラー_1] [ 数値_2 カラー_2] [ 数値_3 カラー_3] ... } "ピグメント修飾子"... } ここで数値_1、数値_2、...のところには、0.0〜1.0までの間の浮動小数点数が入る。カラー_1、カラー_2、...のところには、色の定義が入る。注意:[]括弧は、実際の構文の一部分である。オプションである部分を示すための表記的な記号ではない。この括弧はカラーマップのそれぞれの項目(entry)を囲むものである。マップには、2〜256までの項目が可能である。代替の綴りcolour_mapを使ってもよい。 例えば sphere { <0,1,2>, 2 pigment { gradient x //これは"パターンタイプ"である。 color_map { [0.1 color Red] [0.3 color Yellow] [0.6 color Blue] [0.6 color Green] [0.8 color Cyan] } } } パターン関数は評価され、その結果は、0.0から1.0の値になる。その値が最初の項目よりも小さい場合(この場合0.1）最初の色(赤)が使われる。0.1から0.3の間の値では、2つの色の線形補間(linear interpolation)を用いて黄色と赤をまぜあわせたものが使われる。0.3から0.6の間も同様に黄色から青までが混合される。3番目と4番目の項目はどちらも0.6という値を持っているということに注意して下さい。このことによって、色は青から緑に急に変化する。すなわち0.6より小さい時点では青になり、0.6と正確に等しくなる時点から緑になる。先に進み、0.6から0.8の間では緑とシアンが混ざったものとなる。最後に、0.8以上はシアンが適用される。 もし、色の一定な領域が欲しければ、単に隣あった2つの項目に同じ色を使かえばよい。例えば: color_map { [0.1 color Red] [0.3 color Yellow] [0.6 color Yellow] [0.8 color Green] } この場合0.3から0.6までの間は純粋な黄色となる。 "color_map"キーワードはレンガ(brick)、チェッカー(checker)、ヘキサゴン(hexagon)をおよびイメージマップ(image_map)除く任意のパターンと共に使ってよい。color_map"識別子を宣言して使ってもよい。例えば: #declare Rainbow_Colors= color_map { [0.0 color Magenta] [0.33 color Yellow] [0.67 color Cyan] [1.0 color Magenta] } object{My_Object pigment{ gradient x color_map{Rainbow_Colors} } } 7.6.1.4 ピグメントマップ(Pigment Maps) カラーマップで色を混ぜ合わせる指定に加えて、ピグメントマップを使ってピグメントを混ぜ合わせることもできる。あなたがそれぞれのマップの項目で(色ではなく)ピグメントを指定する事以外は、ピグメントマップの構文はカラーマップの時と同じである。 ピグメントマップの指定は... pigment{ "パターンタイプ" pigment_map { [ 値_1 ピグメント_本体_1] [ 値_2 ピグメント_本体_2] [ 値_3 ピグメント_本体_3] ... } "ピグメント修飾子"... } ここで、"値_1"および"値_2"、...は0.0と1.0を含むその間の値である。"ピグメント_本体"は、pigment {... }構文の中に通常現れるもののすべてであるが、pigmentというキーワードと{}は必要としない。注意:[]括弧は、実際の構文の一部分である。オプションの部分を意味する表記上の記号ではない。この括弧はマップ内のそれぞれの項目を囲むものである。マップ内には2から256項目までの設定が可能である。 例えば: sphere { <0,1,2>, 2 pigment { gradient x //これが"パターンタイプ"である。 pigment_map { [0.3 wood scale 0.2] [0.3 Jade] //これが"ピグメント識別子"である。 [0.6 Jade] [0.9 marble turbulence 1] } } } gradient x関数が0.0から0.3の値を返すときは拡大縮小されたwoodピグメントが使われる。0.3から0.6の間では、ピグメント識別子Jade(ひすい)が使われる。0.6から0.9まではJadeと乱れた(turbulent) marble(大理石)の混ぜ合わされたものが使われる。0.9以上の所では乱れた marbleだけが使われる。 ピグメントマップはあなたが望むだけ何レベルにも複雑にネストさせることができる。マップの中のピグメントはあなたが望むいかなるタイプのピグメントや、ピグメントマップやカラーマップをとることができる。ピグメントマップの項目は単色でもよい。しかし、すべての項目が単色だけなら、レンダリングの速度がわずかながら速くなる、カラーマップを使うべきだ。 完全なピグメントをチェッカー(checker)、ヘキサゴン(hexagon)やレンガ(brick)のようなプロックパターンとともに使っても良い。例えば... pigment { checker pigment { Jade scale.8 } pigment { White_Marble scale.5 } } ブロックパターンの場合pigment {... }の囲いはピグメントの情報をかこうため に必要となる事に注意する。 ピグメントマップはまた、平均ピグメントタイプ(average pigment type)とも使われる。詳細は"Average"を参照して下さい。 あなたは、pigment_map(ピグメントマップ)や、image_map(イメージマップ)を持つ個々のピグメントを使わなくても良い。そのようにするための別の方法については"texture_map"の章を見て下さい。 7.6.1.5 イメージマップ(Image Maps) 他のあらゆる方法で試してもだめで、今まで説明したピグメントがどれもあなたの要求をみたせない時は、あなたの3-Dオブシェクトの周囲を2-Dのピットマップイメージで覆うためにイメージマップという方法を使うことができる。 7.6.1.5.1 イメージマップの定義 イメージマップの構文は次のとおりである... pigment { image_map { "ファイルタイプ" "ファイル名" "修飾子"... } } "ファイルタイプ"の所にはgif、tga、iff、ppm、pgm、png、sysという用語のうち１つが入る。これにクオーテーション(訳注:")で囲まれた貼り付けたいファイル名が続く。いくつかのオプションの修飾子が、ファイルの指定の後に続く。修飾子については、後ほど述べる。注意:初期のPOV-Rayは"ファイルタイプ"の前にいくつかの修飾子をおくことができたが、ここで説明した構文の方が好まれるので、段階的に廃止する。 image_map(イメージマップ)構文の所で定義されるファイル名については、まずホーム(カレント)ディレクトリを検索し、もし見つからなかったら、-L(library path)オプションで指定された、アクティブなディレクトリを検索する。このことは、あなたのイメージマップにつかうファイルを別のサブディレクトリに保存することを容易にし、-Lオプションをコマンドラインで与えて、あなたのイメージマップのディレクトリを指定すればよいのである。 デフォルトの設定では、イメージ(画像)はxy平面に貼り付けられる。イメージは、-z軸方向のどこかにスライド映写機があるかのように、オブジェクトに投影される。イメージはイメージのオリジナルのピクセルサイズによらず、(x,y)座標が(0,0)から(1,1)の四角の中に正確に貼り付けられる。もし、このデフォルトの設定を変えたいなら、オブジェクトの表面に希望どおりにテクスチャやピグメントをマッピングするために、それらを平行移動、回転、拡大縮小をすればいい。 "チェッカー"の章でチェカーピグメントパターンが説明されている。チェッカーは色のついた粘土の中実な立方体で、そこからオブジェクトが刻まれるものとして記述される。イメージマップについてあなたは、それぞれのピクセルはz軸方向に平行に伸びた、長く、細く、正方形で、色のついた棒であると想像すべきである。画像は束ねられたそれらの棒の縦列と横列からできていて、オブジェクトはその束から刻まれる。 もし、このデフォルトの方向を変えたかったら、オブジェクトの表面に希望どおりにテクスチャやピグメントをマッピングするために、それらを平行移動、回転、拡大縮小をすればよい。 7.6.1.5.2 map_type(マップタイプ)オプション デフォルトのxy平面へのイメージの投影は、「平面マップタイプ」と呼ばれている。このオプションは"map_type"キーワードと、それに続くオブジェクトのまわりにイメージを貼り付ける方法を指定する数字を追加することによって変更できる。 "map_type 0"はすでに説明したデフォルトの平面マッピングを設定する。"map_type 1"は球面マッピングの設定である。オブジェクトは、原点に位置している任意の大きさの球(sphere)だとする。y座標は球面マッピングの北極・南極になる。拡大縮小にかかわらず、画像の下端と上端は、正確に極点に接する。画像の左端は、x軸の正方向から始まり、-y方向の回転で東から西に球に画像が貼り付けられる。画像は、球面をきっちり一回転覆う。"once"キーワードは、このタイプのマッピングでは、なんの意味もなさない。 "map_type 2"は、円筒状マッピングの設定をする。y軸に平行な、任意の直径のシリンダだとする。イメージは球面マッピングのようにシリンダを包むがイメージは、y=0からy=1までの1単位の高さだけに限られる。このカラーの帯が"once"キーワードをつけないと、高さまで繰り返される。 最後に"map_type 5"はトーラスまたはドーナツ状マッピングの設定である。これは、xz平面の原点に横たわる主半径が１のトーラスだと仮定する。この画像は球面マッピングやシリンダマッピングと同様に覆われる。しかし、イメージの上端と下端はトーラスの上面または、下面から包み、内側のへりのところで接する。 ３と４についてはまだ開発中である。 注意:map_typeオプションは、bump_mapやmaterial_map構文にもまた、使用できる。 7.6.1.5.3 filter(フィルタ)およびtransmit(透過)ビットマップ修飾子 イメージマップの一部分または全体を透き通らせるために、PNG、GIF、IFF形式の画像やカラ−パレットのための（パレットモードである事が最低条件）フィルタ値と透過値両方、またはどちらかを指定する事ができる。これはファイル名の後に"filter"または、"transmit"キーワードを続けることで指定できる。その2つのキーワードの後には2つの数が続く。最初の数はパレット番号の値で、次にくるのが、透明度の量である。それぞれの値は、コンマで区切る。例えば: image_map { gif "mypic.gif" filter 0, 0.5 // color 0をフィルタのかかった50％の透過色に設定 filter 5, 1.0 // color 5をフィルタのかかった100％の透過色に設定 transmit 8, 0.3 // color 8をフィルタのかかっていない30％の透過色に 設定 } "filter all 値"や"tramsmit all 値"を使って画像全体にフィルタ値や透過値の設定をする事ができる。例えば: image_map { gif "stnglass.gif" filter all 0.9 } 注意:POV-Rayの初期のバージョンではフィルタのかかった透明度を定義するのに"alpha"というキーワードを使っていたが、その言葉はしはしばフィルタのかかっていない透明度を定義するときにも使われていた。そのため"alpha"はもう使わない。 フィルタのかかった透明度とフィルタのかかっていない透明度の違いについての詳細は"filter"と "transmit"の章を見て下さい。 7.6.1.5.4 アルファ・チャンネルを使う(Using the Alpha Channel) フィルタのかかっていない透過透明度をイメージに定義するもう１つの方法にアルファ・チャンネルがある。 もし、あなたが望むのなら、PNGファイルにそれぞれのカラーインデックスに異なる透明度を設定することができる。あなたのペイントプログラムがPNGのこの機能をサポートしるなら、POV形式のファイルでそれぞれの色の透明度を定義するかわりに、あなたのペイントプログラムで、透明度を編集する事もできる。PNGとTGA形式の画像もまた、すべてのアルファ・チャンネル(透明度)の情報を蓄えているため、ピクセルの色に依存しない、むしろ、イメージの中の特定の場所に透明度をもつイメージマップを生成する事ができる。 POVは、透明度の無い場合の定義には、"transmit 0.0"を使い、透明度を最大にするのに、"1.0"を使うけれども、アルファデータの場合は0から255の範囲を逆方向に使う。"alpha data 0"は"transmit 1.0"を意味し"alpha data 255"はtransmit 0.0と同じ効果を作り出す。 7.6.1.6 クイックカラー(Quick Color) POV-Rayのシーンの開発中はレンダリングを速くするために低画質でテストレンダリングする事はしばしば便利である。コマンドラインスイッチ+Qは時間のかかるカラーパターンや、ライティング計算のスピードアップのために使われる。しかし、+Q5の設定のやそれ以下の設定は、ピグメントの計算をせず、グレーのオブジェクトを作り出す。 ピグメント(pigment)にquick_color(クイックカラー)を加えることにより、POV-Rayにパターンピグメントの代わりにどんな単色をクイックレンダリングのために使うかを伝える。例えば: pigment { gradient x color_map{ [0.0 color Yellow] [0.3 color Cyan] [0.6 color Magenta] [1.0 color Cyan] } turbulence 0.5 lambda 1.5 omega 0.75 octaves 8 quick_color Neon_Pink } これは、POV-Rayに"+Q 6"かそれ以上のレンダリングのためにみだれのある(turbulent)gradient(傾斜)パターンを使い、"+Q 5"かそれ以下の画質では、レンダリングテストするために単色のNeon_Pink(ネオンピンク)を使うことを伝えている。 注意:以下のような単色のピグメント pigment {color Magenta} は、自動的にquick_color(クイックカラー)にその値を設定する。あなたは、もし望むならこれを無効にすることもできる。あなたは10個の球を画面上に描き、それらはすべて黄色だと仮定する。もし、それらを別々に表したいのなら、それぞれに異なるquick_colorを以下のように設定するとよい: sphere { <1,2,3>,4 pigment { color Yellow quick_color Red } } sphere { <-1,-2,-3>,4 pigment { color Yellow quick_color Blue } } などである。"+Q 6"かそれ以上の画質では、それらはすべて黄色になるが"+Q 5"かそれ 以下では、それぞれ別の色になり、あなたはそれらを識別できる。 7.6.2 法線(Normal) レイトレーシングは，反射や屈折や照明の効果を表現するドラマティックな方法として知られている。我々の知覚の多くが物体の反射特性に依っている。レイトレーシングでは，実際にはそこにない，複雑な細部を見せるように知覚に錯覚させるのにこれを利用することができる。 あなたがオブジェクトにとてもでこぼこのある表面が欲しかったと仮定しなさい。たくさんの凹凸(bump)を数学的にモデル化することはとても難しい。しかしわれわれは凹凸の外観を表面の光の反射を変化させることによってシミュレートすることができる。反射計算は、表面法線ベクトルと呼ばれるベクトルに依存する。これは、表面から外側に向かう方向を指す表面に垂直なベクトルである。人為的ににこの法線ベクトルを変更する（あるいはかき乱す）ことによって、あなたは凹凸をシミュレートすることができる。 normal {... } 構文はオブジェクトに適用される法線の動揺のパターンを定義するテクスチャの一部分である。ピグメント(pigment)構文のように、タイピングを節約するためにテクスチャブロックの囲みは省略できる。しかし、そこには暗黙のテクスチャ(texture)があることを忘れないで下さい。例えば... //これは... //このように短くなる... object { object { My_Object My_Object texture { pigment {color Purple} pigment {color Purple} normal {bumps 0.3} normal {bumps 0.3} } } } 法線パターンを付加しても実際には表面を変更しないということを注意してください。それは、表面で光が反射や屈折する方法に影響するだけであり、それででこぼこに見えるのである。 法線(normal)の定義の最も完全な形式は以下のようである: normal { 法線_識別子 パターンタイプ 浮動小数点数値 法線_修飾子 変換... } normalの中のそれぞれの項目はオプションであるが、もし存在する場合は期待通りの結果が保証されるように上に示した順序にすべきである。"法線_識別子"以降のいずれの項目もその識別子で与えられた設定を修正あるいは上書きして無効にする。識別子が指定されない場合、それらの項目は現在のデフォルトテクスチャの法線(normal)の値を修正する。"パターンタイプ"にはオプショナルな浮動小数点数値が続く。それは凹凸(bumps)の見かけの深さを制御する。代表的な値は0.0 から 1.0の範囲であるが、任意の値が使える。負の値はパターンを反転する。何も指定されないときのデフォルトの値は0.5である。 有効な"法線_修飾子"はtranslate、rotate、scale、turbulence、wave shapeおよびwarp構文などの一般の"パターン_修飾子"とともに、slope_map、normal_map、bump_mapおよびbump_size構文である。これらの修飾子は法線(normal)だけに適用され、テクスチャの他の部分にはなされない。修飾子は最後に指定すべきである。 ３つの基本的なタイプの"法線_パターンタイプ"がある。それらはパターン法線(pattern normals)、特定法線(specialized normals)およびバンプマップ(bump maps)である。それらは、一緒に使うことができる修飾子のタイプが異なる。元々POV-Rayはいくつかのピグメントのためだけに使うパターンがあり、その一方で法線だけに使うパターンがあった。POV-Ray 3.0からは、すべてのパターンをピグメントと法線に使えるようになった。例えば、現在はripplesをピグメントとして、woodを法線タイプとして使うことも有効である。bumps、dents、ripples、waves、wrinklesのパターンおよびbump_mapはかつてはもっぱら法線パターンでありピグメントとしては使えなかった。なぜならばこれらの6つのタイプは専用の法線の修正計算を用いるため、slope_map、normal_mapあるいはwave shape 修飾子を持つことができないからである。すべての他の法線パターンタイプはそれらを使ってもよい。 7.6.2.1 傾斜マップ(Slope Maps) 傾斜マップ(slope map)は法線パターン修飾子であり、ユーザーにでこぼこのフィーチャーの正確な形状の非常に多くの制御を与える。それはgradient法線パターンで示すのが最善である。あなたが以下を持つと仮定しよう... plane{ z, 0 pigment{ White } normal { gradient x } } これは傾斜(ramp)波パターンを与え、それは小さな直線の坂の様に見える。その坂はx=0の点からx=1まで登り、それからx=1からx=2まで登るのを繰り返すために急に0まで再び下る。傾斜マップはこの単純な直線の坂をほとんどすべてのあなたの望む波形にする。構文は次のとおりである... normal{ パターンタイプ 値 slope_map { [ 数値_1 点_傾斜_1] [ 数値_2 点_傾斜_2] [ 数値_3 点_傾斜_3] ... } 法線_修飾子... } 注意:括弧[]は実際の構文の一部である。それはオプションの部分を表している表記上の記号ではない。この括弧は傾斜マップ中の各項目を囲む。マップ中で2 から256の項目数が可能である。 数値_1、数値_2、...は浮動小数点数値で0.0と1.0の範囲でそれらを含む。点_傾斜_1、点_傾斜_2、... は<0,1>のような2成分ベクトルで、その最初の値は波の見かけの高さを与え、二番目の値はその点での波の傾斜を示す。高さは0.0と1.0の範囲であるべきだが任意の値を使うことができる。 傾斜の値は単位距離あたりの高さの変化である。例えば、傾斜がゼロであれば平を意味し、1.0の傾斜は45度の角度の登りの傾斜で、-1の傾斜は45度の下りの傾斜を意味する。 理論的には真っ直ぐ上に行く傾斜は無限の傾斜である。実際は、傾斜の値は-3.0 から +3.0の間に保つべきである。これが視覚的な外見上だけの傾斜であることを心にとどめておきなさい。法線は表面を実際に変化させることはない。 例えば、ここに最初の半分を登り、２番目の半分では下って戻り、中心で先端がとんがった三角形の波をどのように作るかを示す。 normal { gradient x // これがパターンタイプ slope_map { [0 <0, 1>] // 底から始め、上に傾斜 [0.5 <1, 1>] // 半分まで来たら頂上につくがまだ登っている [0.5 <1,-1>] // 急に下に傾斜する [1 <0,-1>] // 底で下り坂が終わる } } パターン関数は評価され、その結果は0.0から1.0の範囲になる。最初の項目はx=0において見かけの高さが0で傾斜が1であることを意味する。x=0.5で高さは1になり傾斜はまだ上向きで1である。三番目の項目もまたx=0.5(実際には0.5より僅かに上の部分)で高さ1だが傾斜が下りの-1であることを指定する。最後にx=1で再び高さ0になり傾斜はまだ下りの傾斜(slope) -1。である。 この例では点を直線を用いてつないでいるけれども、その形状は実際は3次スプラインである。この例では滑らかな正弦波を作る。 normal { gradient x // これはパターンタイプ slope_map { [0 <0.5, 1>] // 真ん中から始め、上に傾斜 [0.25 <1.0, 0>] // 波の頂上では平らな傾斜 [0.5 <0.5,-1>] // 真ん中で下に傾斜 [0.75 <0.0, 0>] // 底で平らな傾斜 [1 <0.5, 1>] // 真ん中で上りの傾斜で終わる } } この例は、高さ0.5で上へ傾斜する傾斜1で始まる。道のりの1/4を通るとき高さ1で平らな傾斜0の曲線の頂上になる。スタートと終わり傾斜が異なるので、これらの二つの間の空間は、ゆるやかなカーブである。道のりの半分で半分の高さで、3/4の底まで下りになる。終端では周期を完了するために再び傾斜1で登っている。サンプルシーンの中のslopemap.povにもっと多くの例がある。 slope_mapはbrick、checker、hexagon、bumps、dents、ripples、waves、wrinklesおよびbump_map以外の任意のパターンと使われても良い。 あなたは傾斜マップ(slope map)識別子を宣言して使用しても良い。例えば: #declare Fancy_Wave = slope_map { // さあファンシー(fancy)なのを作ろう [0.0 <0, 1>] // ここで小さい三角形を実行する [0.2 <1, 1>] // 登って [0.2 <1,-1>] // 下る [0.4 <0,-1>] // ここまで [0.4 <0, 0>] // 平らな場所 [0.5 <0, 0>] // ここまで。 [0.5 <1, 0>] // 正方形の波の先端の縁 [0.6 <1, 0>] // 後ろの縁 [0.6 <0, 0>] // 再び平ら [0.7 <0, 0>] // ここまで。 [0.7 <0, 3>] // スカラップ(scallop:扇形)のスタート [0.8 <1, 0>] // 頂上は平ら [0.9 <0,-3>] // ここで終わり。 [0.9 <0, 0>] // 残りは1.0まで平ら。 } object{ My_Object pigment { White } normal { wood slope_map { Fancy_Wave } } } 7.6.2.2 法線マップ(Normal Maps) ほとんどの場合、あなたは一つの法線パターンを全体の表面に適用するだろう、しかし、また、あなたは法線マップを用いて法線のパターンや混合(blend)を作成しても良い。法線マップの構文はあなたが各マップエントリに法線を指定することを除いてピグメントマップと同一である。 法線マップは以下のように指定される... normal{ パターンタイプ normal_map { [ 数値_1 法線_本体_1] [ 数値_2 法線_本体_2] [ 数値_3 法線_本体_3] ... } 法線_修飾子... } ここで 数値_1, 数値_2,...は0.0から1.0までの間に含まれる浮動小数点数値である。法線_本体はnormal {... }構文内に通常現れる物であれば何でも良いが、normalキーワードと{}括弧は必要ない。注意:[]括弧は実際の構文の一部である。それらはオプションの部分を表す表記上の記号では無い。この括弧はマップ内の各エントリを囲む。マップ内には2〜256のエントリが存在しても良い。 例えば normal { gradient x //これがパターンタイプ normal_map { [0.3 bumps scale 2] [0.3 dents] [0.6 dents] [0.9 marble turbulence 1] } } gradient x 関数が0.0から0.3までの値を返すとき、拡大されたbumps(でこぼこ)法線が用いられる。0.3から0.6ではdents(くぼみ)が、0.6から0.9まではdentsとturbulent marble(乱れた大理石)の混合が用いられる。 法線マップはあなたが望む任意の複雑さのレベルに入れ子に(ネスト)しても良い。マップ内の法線は傾斜マップ(slope maps)あるいは法線マップ(normal maps)あるいはあなたの望む任意のタイプの法線(normal)を持っても良い。 法線マップはまた平均法線タイプ(average normal type)とともに用いられる。詳しくは「平均:Average」を見て欲しい。 全ての法線はチェッカー(checker)、六角形(hexagon)および煉瓦(brick)などのブロックパターンとともに用いられても良い。例えば... normal { checker normal { gradient x scale.2 } normal { gradient y scale.2 } } } 注意:ブロックパターンの場合は法線の情報のまわりのnormal {... }の囲いは必要である。 あなたはnormal_map(法線マップ)あるいは個々の法線をbump_map(バンプマップ)とともに用いてはならない。これをするための別の方法については"texture_map"を見て欲しい。 7.6.2.3 バンプマップ(Bump Maps) 他のすべてがうまくゆかず、上述の法線パターンのどれもがあなたの要求を満たさない場合、あなたは2-Dビットマップのバンプ(凹凸)パターンをあなたの3-Dオブジェクトのまわりに巻き付けるためにバンプマップ(bump map)を用いることができる。 イメージマップのように形状の上にイメージの色を配置する代わりに、バンプマップはその点におけるイメージの色に基づいて法線をかき乱す。結果は、そのイメージが表面に浮彫りされたように見える。デフォルトで、バンプマップは、ピクセルの実際のカラーの輝度を用いる。色は高さを計算する前に内部的にグレースケールに変換される。黒は低い地点であり、白は高い地点である。イメージのインデックス値(パレット番号)が、その代わりに用いられるかもしれない(以下のセクション「Use_Index および Use_Color」を見て下さい)。 7.6.2.3.1 バンプマップを指定する(Specifying a Bump Map) bump_mapの構文は... normal { bump_map { ファイルタイプ "ファイル名" ビットマップ修飾子... } 法線_修飾子... } ここで、"ファイルタイプ"は以下のキーワードgif、tga、iff、ppm、pgm、png あるいはsysの一つである。これに有効な文字列式を用いたファイルの名前が続く。いくつかのオプションの修飾子がこのファイル指定に続くかも知れない。修飾子は以下で述べる。注意:初期のバージョンのPOV-Rayは"ファイルタイプ"の前に修飾子を許したが、その構文は、ここで記述された構文を採用して段階的に排除されている。 bump_map構文の中で指定されたファイル名は、ホーム（カレント）ディレクトリを最初に検索して、それで見つけられなければ、+LスイッチかLibrary_Pathオプションによって指定されたディレクトリの中を捜されるだろう。これは、別のサブディレクトリにあなたのすべてのバンプマップファイルを保有して、それらにライブラリパスを指定するのを容易にする。注意:もしあなたがLibrary_Pathとしてそれらを指定しなければ、オペレーティングシステムのデフォルトパスは捜されない。 デフォルトで、バンプパターンは、x-y平面上へマップされる。まるでスライドプロジェクターが-z-方向のどこかにあるように、バンプはオブジェクトの上へ投影される。バンプパターンは、ビットマップのオリジナルのピクセル数のサイズに関係なく、正確に（x,y）座標（0,0）から（1,1）までの正方形の領域を満たす。もし、あなたがこのデフォルトを変えたいならば、あなたはオブジェクトの表面にマップするために必要に応じて、法線かテクスチャを平行移動(translate)、回転(rotate)あるいは拡大縮小(scale)しても良い。 ファイル名には必要に応じて一つあるいはそれ以上の"ビットマップ修飾子"を続けても良い。bump_size、use_colorおよびuse_index修飾子はバンプマップに特定のものであり、後のセクションで論じる。他の一般的なビットマップ修飾子のために「ビットマップ修飾子」を見て欲しい。 bump_map構文の後、まだnomal構文の中で、あなたは、slope_map(傾斜マップ)とパターン波(pattern wave)形式を除いて、任意の正当な法線修飾子を適用することもできる。 7.6.2.3.2 バンプサイズ(Bump_Size) 相対的バンプサイズは、bump_size修飾子を用いて拡大縮小することができる。バンプサイズの値は0以外の任意の値が可能であるが、代表的な値はだいたい0.1から0.4あるいは0.5ぐらいの高さである。 normal { bump_map { gif "stuff.gif" bump_size 5.0 } } 元々はbump_sizeはバンプマップ内部だけで使えるものであったが、現在は任意の法線とともに用いることができる。典型的には、以前に定義されたサイズを無効にするために用いられる。例えば: normal { My_Normal //これは以前に定義された法線識別子 bump_size 2.0 } 7.6.2.3.3 Use_Index および Use_Color 通常、バンプマップはマップ内のピクセルの色を0.0から1.0の範囲のグレイスケール強度に変え、その値に基づいてバンプを計算する。あなたがuse_indexを指定するならば、バンプマップは、その点のバンプの高さとして計算するために、色のパレット番号を用いる。それで、色番号0は低く、そして色番号255は（画像が256のパレットエントリを持っているならば）高くなる。インデックスを用いているとき、ピクセルの実際のカラーは重要でない。このオプションは、パレットベースの(画像)フォーマットで利用可能なだけである。use_colorキーワードはそのカラー方法が使われるべきだということを明示的に書きとめるために指定されても良い。代替のつづりuse_colourもまた有効である。これらの修飾子はbump_map構文内部でのみ使用できる。 7.6.3 仕上げ(Finish:フィニッシュ) 表面の仕上げ(finish)特性は、その外観に大いに影響を及ぼすはずである。どのように、光は反射するか？光が通過するとき、何が起こるか？どんな種類のハイライトが見えるか。これらの質問に答えるために、あなたは仕上げ(finish)構文を必要とする。 finish {... } 構文はテクスチャの一部分であり、オブジェクトに適用される様々な仕上げ特性を定義する。ピグメントあるいは法線構文のようにタイピングを節約するためにテクスチャブロックの囲みを省略できる。けれどもテクスチャが意味されていることを忘れないで下さい。例えば... これは... このように短縮できる... object { object { My_Object My_Object texture { pigment {color Purple} pigment {color Purple} finish {phong 0.3} finish {phong 0.3} } } } 最も完全な仕上げの定義の形式は以下のようである: finish { 仕上げ_識別子 [ ambient カラー ] [ diffuse 浮動小数点数 ] [ brilliance 浮動小数点数 ] [ phong 浮動小数点数 ] [ phong_size 浮動小数点数 ] [ specular 浮動小数点数 ] [ roughness 浮動小数点数 ] [ metallic [ 浮動小数点数 ] ] [ reflection カラー ] [ refraction 浮動小数点数 ] [ ior 浮動小数点数 ] [ caustics 浮動小数点数 ] [ fade_distance 浮動小数点数 ] [ fade_power 浮動小数点数 ] [ irid { thickness 浮動小数点数 turbulence ベクトル } ] [ crand 浮動小数点数 ] } "仕上げ_識別子"はオプションであるが、他のすべての項目より先になければならない。"仕上げ_識別子"の後の項目は、その識別子の中で与えられた設定を修正するか、無効にする。識別子が指定されないならば、項目は現在のデフォルトテクスチャの仕上げ値を修正する。注意:仕上げの内部に変換は許されない。なぜなら仕上げの項目は全表面を一様に覆うからである。 7.6.3.1 環境光、周囲光(Ambient) あなたが暗い陰になった領域で見る光は他のオブジェクトの拡散反射(diffuse reflection)から来るものである。この光はレイトレーシングを用いて直接モデル化はできない。しかし、われわれは陰の領域内の光をシミュレートするために環境光照明(ambient lighting)と呼ばれるトリックを使うことができる。 環境光は、部屋の至る所に拡散させられる光である。それは至る所で跳ね返り、光が直接輝いていないところでも僅かにオブジェクトを照らすようにする。実際の環境光を計算するには非常に多くの時間がかかる。そこでわれわれは光がそのテクスチャを実際に輝かせているかどうかに関わらず、わずかな量の白い光を各々のテクスチャに加えることによって環境光をシミュレートする。 これは完全に陰の中にある形状の一部がまだほんの僅かそれらの表面色を持つことを意味する。テクスチャ内の環境光は用いられている形状に影響を及ぼすだけであるけれども、それはまるでそのテクスチャが輝くようである。 その構文はカラーを呼び出すけれども、大抵一つの浮動小数点数値が指定される。例えば浮動小数点数値0.3はフルカラーベクトル<0.3,0.3,0.3,0.3,0.3>にプロモートされるが、赤、緑、青の部分が使われるだけなのでこれは受け入れられる。 デフォルト値は非常に小さい環境光(0.1)である。この値は0.0 から 1.0まで可能である。環境光は陰になった領域と陰にならない領域両方に影響するのでもしambient値を上げるとあなたはdiffuse値を下げたくなるかも知れない。 注意:本方法はまわりのオブジェクトの色は考慮しない。もしあなたが赤い壁、床、天井を持つ部屋に入ると、あなたの白い衣服は反射光によってピンクに見えるだろう。POV-Rayの環境光(ambient)の近道ではこれらを考慮しない。また、鏡の中で輝いているフラッシュライトのような鏡面反射する間接照明をモデル化する方法もない。 あなたが２つの方法の一つを用いて環境光を色づけることができる。あなたはそれぞれの仕上げ構文のambientキーワードの後ろに浮動小数点数でなく代わりにカラーを指定しても良い。例えば finish { ambient rgb <0.3,0.1,0.1> } //ピンクの環境光 あなたはまたグロバールなambient_light設定を用いてオブジェクトの環境照明の計算する際の全部の環境光を指定しても良い。公式は AMBIENT = FINISH_AMBIENT * GLOBAL_AMBIENT_LIGHT_SOURCE で与えられる。 7.6.3.2 拡散反射項目(Diffuse Reflection Items) 光が表面で反射するとき、物理法則では光は入射角に正確に同じ角度で表面を離れるといっている。これはプールテーブルのバンパーで跳ね返るビリヤードのボールの進路と同様である。この完全な反射は鏡面反射(specular reflection)と呼ばれる。しかし、このように光を反射させるのは非常に滑らかに磨かれた表面だけである。ほとんどの場合、光は反射して、表面の粗さによって四方八方に拡散させられる。この拡散は拡散反射(diffuse reflection)と呼ばれる。なぜならばその光はいろんな方向へ拡散あるいは広がるからである。それは我々が見る反射された光の大多数を説明する。 POV-Rayと他のほとんどのレイトレーサーはこれらの3つのタイプのうちの一つの照明(illumination)を直接シミュレートできるだけである。それは実際の光源から直接来る光、他の鏡のようなオブジェクトから鏡面反射して来る光(例えば鏡にフラッシュライトを輝かせる)、および最後であるが最小ではない、拡散反射によって他のオブジェクトから来る光である(机の下や隅の暗い領域を見てごらん:ランプは直接はその場所を照明しないかも知れないが、光がすぐ近くのオブジェクトから拡散反射してくるのでまだほんの少し見える)。 7.6.3.2.1 拡散反射(Diffuse) キーワード diffuseは仕上げ(finish)構文の中でどのくらい多くの光が拡散反射によって光源から反射して直接来るかを制御するために使われる。例えば finish {diffuse 0.7} は70%の見える光が直接照明から来ることを意味する。デフォルト値はdiffuse 0.6である。 7.6.3.2.2 光輝(Brilliance) オブジェクトからの拡散反射による直接光の量はそれがあたる表面の角度に依存する。光が浅い角度で当たる場合、それはより少なく照らす。それが直接表面の真上だとより多く照らす。brilliance(光輝)キーワードは光が投射(incidence)角に依存して減退(fall off)する方法を変化させるために仕上げ構文で使うことができる。これはオブジェクト上への基本的な拡散照明のタイトネス(tightness)を制御し、わずかに表面の光沢(shininess)の外観を調整する。オブジェクトはそれらのbrilliance(光輝)を増やすことによってより金属的(metallic)に見える。デフォルト値は1.0である。だいたい10.0前後の高い値は中間から低い角度においてより少ない減退を光に引き起こす。brillianceの値に制限はない。特定の状況に対してはどのように動作するのかを実験してみるのが最も良い。これは、ハイライティング(highlighting)と協力して最もよく用いられる。 7.6.3.2.3 Crand粗さ(Crand Graininess) コンクリートや砂のようなとても粗い表面は、暗い粒の粗さをそれらの外見上の色に提示する。これは、表面の穴やくぼみの影に起因する。crandキーワードは、直接照明による拡散反射の中に小さくランダムに暗くなることを引き起こすために付け加えらることができる。代表的な値は、crand 0.01からcrand 0.5かそれ以上に及ぶ。デフォルト値は0である。例えば: finish { crand 0.05 } この機能によって導入された粒あるいはノイズはピクセル毎の基準で適用される。このことは、遠くにあるオブジェクトが近くにあるオブジェクトと同じように見えることを意味する。この効果はまた、あなたがレンダリングのために用いている解像度によって異なるように見る。これらの理由から、これは粗い表面をモデル化するにはあまり正確な方法とはいえないけれどもいくつかのオブジェクトはそれでも少しcrandを投げ入れるとよりよく見える。 注意:これはアニメーションのレンダリングでは用いるべきでない。これは、POV-Rayの中の2,3の本当にランダムな機能の一つのであって、crand値を使ってアニメーションされたテクスチャには、ピクセルが飛んでいる悩ましいフリッカーを生じるだろう。 7.6.3.3 ハイライト(Highlights) ハイライトは、滑らかな表面で光源が反射するときに現れる明るい場所(スポット)である。それらは、鏡面反射と拡散反射の混合である。それらは視線角度と照明角度に依存するので、鏡面反射光のようである。しかし、いくらかの拡散反射も起こるので拡散反射光のようでもある。正確にハイライトをモデル化するためには、あなたはミクロファセット(微細小面)と呼ばれる何千もの微細なでこぼこの鏡面反射の計算をしなければならない。多くのミクロファセットが観察者に面していると、オブジェクトがより多く光るように見え、よりきついハイライトが起こる。POV-Rayは、ミクロファセットを計算することなくハイライトをシミュレートするために2つの異なるモデルを用いる。それらは、鏡面(specular)モデルとフォン(Phong)モデルである。 注意:鏡面ハイライトとフォンハイライトは互に排他的ではない。両方を指定することが可能である。そして、それらの両方が効果を持つだろう。しかし、通常はどちらか一方を指定するだけだろう。 7.6.3.3.1 フォンハイライティング(Phong Highlights) phong(フォンあるいはフォーン)キーワードはオブジェクトのフォンハイライティングの量を制御する。それはオブジェクトの上に光源の色が反射した明るい光るスポットを引き起こす。 フォンの方法は光源から観察者への鏡面方向に面したファセットの平均を測定する。 Phongの値は代表的には0.0 から1.0である。ここで1.0の値はハイライトの最も明るい領域(中心)に光源の色に対して完全な飽和(saturation)を引き起こす。デフォルトのphong 0.0は、ハイライトを与えない。 ハイライトスポットのサイズは、phong_size値によって定義される。より大きなフォンサイズ(phong size)はよりきついあるいは小さいハイライトでより明るい外観になる。より小さいフォンサイズはよりゆるいあるいは大きいハイライトになりより光沢のない外観になる。 任意の値を用いてもよいけれども、代表的な値の範囲は1.0 (非常に鈍い)から250(よく磨かれた)である。phong_sizeが指定されなければ、デフォルトのフォンサイズは40（プラスチック）である。例えば: finish { phong 0.9 phong_size 60 } 7.6.3.3.2 鏡面ハイライト(Specular Highlight) 鏡面ハイライト(specular highlight)はフォンハイライティングに非常に類似しているが、少し異なるモデルを用いる。鏡面モデルは実際の鏡面反射により密接に類似していて、より信頼できるオブジェクトの地平線の近くで起きるハイライティングの広がりを備えている。 specular値は代表的には0.0から1.0であり、ここで1.0はハイライトの最も明るい領域(中心)で光源の色の完全な飽和を引き起こす。デフォルトのspecular 0.0はハイライトを与えない。 スポットのサイズはroughness(粗さ)として与えられる値で定義される。代表的な値の範囲は1.0 (とても粗い - 大きなハイライト)から0.0005 (とても滑らかな - 小さいハイライト)である。もしroughnessが与えられないときのデフォルトの値は0.05(プラスチック)である。 間違った値をroughnessに指定することは可能であるが、それはそのファイルをレンダリングしようとするときにエラーを生じる。 0を使わないで下さい。そしてもしエラーになったら、エラーを引き起こすようなとてもとても小さなroughness値を使っていないかチェックして下さい。例えば: finish {specular 0.9 roughness 0.02} 7.6.3.3.3 メタリックハイライト修飾子(Metallic Highlight Modifier) キーワードmetallicはフォンあるいは鏡面ハイライトとともに用いられる。このキーワードは、金属的な表面の反射をモデル化する経験的な関数によって、ハイライトの色が計算されるということを示す。 金属的な表面からの鏡面反射した白色光は、投射角度が90に接近し再び白くなる場合を除いて、その表面の色を持つ。 metallicキーワードには数値を続けて上記の効果の持つ影響を指定しても良い(デフォルト値は1である)。例えば: finish { phong 0.9 phong_size 60 metallic } 7.6.3.4 鏡面反射(Specular Reflection) 光が拡散せずにオブジェクトに当たった角度と同じ角度で反射する場合、それを鏡面反射と呼ぶ。このような鏡のような反射は仕上げ(finish)構文のreflectionキーワードで制御される。例えば: finish { reflection 1.0 ambient 0 diffuse 0 } これは、オブジェクトに反射する仕上げを与える。シーンの中のすべての他の要素を反射するだろう。構文上はカラーを呼び出すが、通常は一つの浮動小数点数値がそのキーワードの後ろに指定される。例えば浮動小数点数値0.3は完全なカラーベクトル <0.3,0.3,0.3,0.3,0.3>にプロモートされる。これは赤、緑、青成分だけが使われるため有効である。 値は0.0から1.0の範囲が可能である。デフォルトではreflectionは無い。 reflectionをテクスチャに加えるとレンダリング時間が長くかかる。これは付加的な光線をトレースしなければならなくなるからである。反射光は浮動小数点数ではなくカラーを指定することによって色を付けても良い。例えば finish { reflection rgb <1,0,0> } は赤い光だけを反射する現実の赤い鏡を与える。 注意:このような反射はspecular(鏡面反射)と呼ばれるがspecularキーワードではコントロールされない。そのキーワードは鏡面ハイライト(specular highlight)をコントロールする。 7.6.3.5 屈折(Refraction) 光が密度の高い媒体に入りあるいは出る時、表面を通り抜ける光の光線の進路は曲げられる。そのような曲げは屈折と名づけられる。通常、POV-Rayの透明あるいは半透明な表面は光を屈折させない。仕上げ(finish)構文にrefraction 1.0を加えると屈折がonになる。 注意:あなたはrefraction 0 あるいは refraction 1だけを用いることを推奨される(あるいはさらによいrefraction off および refraction on )。中間の値は物理的特性に対応しない方法で屈折させられた光を暗くするだろう。このバグが発見される前に、多くのPOV-Rayシーンは中間の屈折値で作成されたので、この機能は維持された。屈折光の輝度を減らすより適当な方法はピグメント構文のカラーのフィルタ値あるいは透過値を変更することである。また、refractionによってオブジェクトが透明にはならないことに注意されたい。カラー内にゼロでないフィルタあるいは透過値がある場合のみ透明度が生ずる。 光の曲げあるいは屈折量は材料の密度に依存する。空気、水、水晶、そして、ダイヤモンドのすべては異なる密度を持ち、異なる屈折をする。屈折率(index of refraction)あるいはior値は科学者によって物質の相対的密度を記述するために用いられる。iorキーワードは、POV-Rayでその値を指定するために用いられる。例えば: texture { pigment { White filter 0.9 } finish { refraction 1 ior 1.5 } } 1.0のデフォルトior値は屈折を与えない。空気の屈折率は1.0であり、水は1.33、ガラスは1.5、そしてダイヤモンドは2.4である。ファイルconsts.incは、いくつかの役に立つiorの値をあらかじめ定義する。 注意:もしテクスチャがフィルタ成分を持ち、屈折の値を持たずにiorが供給されるとレンダラーは光を曲げることなく単に表面を通して透過させるだろう。階層化されたテクスチャの中で、refractionとiorキーワードは最後のテクスチャになければならない。さもなければそれらは効果をもたないだろう。 7.6.3.5.1 光の減衰(Light Attenuation) 光の減衰(light attenuation)は光が半透明のオブジェクトを通して進むときの光の強度の減少をモデル化する。その構文は: finish { fade_distance フェイド距離 fade_power フェイド指数 } fade_distanceキーワードは、光が半分の強度になるまでに移動しなければならない距離を決め、fade_powerキーワードが光がどれくらい速く減退(fall off)するかを記述する。現実的な効果のために1〜2のフェイド指数(fade power)を用いるべきである。 減衰(attenuation)は光源の減衰で使われた公式と同様の式で計算される。 1 attenuation = -------------------------------------- 1 + (d / フェイド距離) ^ フェイド指数 (訳注:pov3demo\lights\fadel1.pov/fadelt2.povが参考になるでしょう。) 7.6.3.5.2 模造火線(Faked Caustics) 火線(Caustics)は鏡面反射あるいは屈折する表面で光が反射あるいは屈折したときに起こる光の効果である。テーブルの上に立っている水の入ったグラスを想像しよう。もし、太陽光がグラスに当たると、テーブルの上に光のスポットが見えるだろう。スポットのいくつかはグラスで反射したために起こるもので、いくつかはグラスの中の水による屈折により起こる。 それらの効果を実際に計算するのは非常に難しく、時間を消費する処理なので、(不可能ではないけれども) POV-Ray は屈折による火線をシミュレートするためにまったく単純な方法を用いる。この火線の効果は半透明なオブジェクトによる影になった領域に限られる。反射する表面やオブジェクトで影にならない部分では火線の効果は得られない。 構文は: finish { caustics POWER } (訳注:caustic1.pov,caustic2.povが参考になるでしょう。) 7.6.3.6 虹色の光彩(Iridescence) 虹色の光彩(Iridescence)あるいはNewtonの薄膜干渉は微薄な透明フィルムを重ねた表面の光の効果をシミュレートする。 この効果は水たまりの上の油膜やシャボン玉の虹色の色合いのようなものである("irid_wavelength"も見て下さい)。 構文は: finish { irid { AMOUNT thickness 浮動小数点数 turbulence ベクトル } } この仕上げ(finish)は、光源と表面の間の角度の関数として表面の色を変更する。この効果は位置と光源から表面への角度に関連して働くので、手続き的なピグメントパターンと同じには作用しない。 AMOUNTパラメータは全表面色への虹色の光彩効果の寄与である。経験則として0.25（25 %の寄与）あたりか、より小さい値を守って下さい。でも試してみなさい。表面が白くなりすぎたら表面のdiffuse値あるいはおそらくambient値を低くしなさい。 thicknessキーワードはフィルムの厚さを表す。これは、thickness値がオブジェクトのスケール(scale)と関係を持っていないので設定するには使いにくいパラメータである。それを変えることは、その効果のスケールあるいはにぎやかさ(busy-ness)に影響を及ぼす。厚いフィルムは大きな色の領域を持つが、非常に薄いフィルムは高い周波数の色の変化をもつ。 フィルムの厚さは、turbulenceキーワードで変えることができる。虹色の光彩では動乱(turbulence)の量だけが指定できる。オクターブ(octaves)、ラムダ(lambda)とオメガ(omega)値は、内部にセットされて、現時点ではユーザによる調節はできない。 それに加えて、バンプパターンの使用によりオブジェクトの法線をかき乱すことは虹色の光彩(iridescence)に影響を及ぼす。 好奇心の強い人のために:薄膜干渉が起こるのは、光線がその膜にあたったとき、光の一部はその表面から反射するが、一部は膜の内部に透過する。この表面下の光線は膜を通過し最終的には不透明な支持層(substrate)で反射する。光はわずかに表面から反射された光線と位相を異にしてフィルムから現れる。 この位相の変化が成分の色の波長を変化させる干渉を生じさせ、結果としてある波長は増強され 他の波長はキャンセルされる。これらの成分が再び結合された結果虹色の光彩となる。 この機能のために用いられた概念は以下の書籍に由来した:Fundamentals of Three-Dimensional Computer Graphics by Alan Watt (Addison-Wesley). (訳注:irid.pov,iridwlen.povを参考にして下さい。) 7.6.4 ハロー(Halo) 重要な注意:POV-Ray 3.0のハローの機能はいくぶん実験的なものである。これらの機能の設計とインプリメンテーション(実現)は将来のバージョンで変更される可能性が高い。我々は、3.0でこれらの機能を用いているシーンが、今後のリリースで同じくレンダリングできるか、あるいは言語構文の後ろ向き互換性を完全に維持することができるかどうかを約束することができない。 ハロー(halo[he'ilow]:光輪、暈輪)は小さい粒子が光あるいはそれ自身の放射と影響し合うときに起こる大気の効果のいくつかをシミュレートするために用いられる。それらの効果には雲、霧、炎、などが含まれる。 ハローはオブジェクトに付加され、コンテナオブジェクトと呼ばれ、オブジェクトは完全に満たされている。もしそのオブジェクトが部分的にあるいは完全に半透明で、そのオブジェクトがhollow(中空)に指定されていれば(より詳しくはセクション「中空(Hollow)」参照)、ハローは見える。したがってハローの効果はオブジェクトが覆う空間に限られる。このことは常に心の中にとどめておくべきである。 ハローが実際に何の様に見えるかはたくさんのパラメータに依存する。まず第一に、あなたはあなたがどんな種類の効果をシミュレートしたいかを指定しなければならない。その後あなたは粒子の分布を定義する必要がある。これは基本的には2ステップでできる:マッピング関数を選択し、密度関数を選ぶ。最初の関数はワールド座標を一次元の間隔へマップし、他の関数はこの線形な間隔がどのように最終的な密度値にマップされるかを記述する。 粒子の色とそれらの半透明性(translucency)のような、粒子の特性は、カラーマップによって与えられる。マップッピング処理によって計算された密度値は、このカラーマップを用いて適当なカラーを決めるために用いられる。 ハローの体積サンプル(volume sample)と、各々の間隔の強度(intensities)と不透明(opacity)を累積するために光線進行(ray marching)処理が用いられる。 続くセクションですべてのハローのパラメータをより詳しく記述する。完全なハローの構文は: halo { attenuating | emitting | glowing | dust [ constant | linear | cubic | poly ] [ planar_mapping | spherical_mapping | cylindrical_mapping | box_mapping ] [ dust_type DUST_TYPE ] [ eccentricity ECCENTRICITY ] [ max_value 最大値 ] [ exponent 指数 ] [ samples SAMPLES ] [ aa_level AA_LEVEL ] [ aa_threshold AA_THRESHOLD ] [ jitter JITTER ] [ turbulence ] [ octaves OCTAVES ] [ omega OMEGA ] [ lambda LAMBDA ] [ colour_map カラーマップ ] [ frequency FREQUENCY ] [ phase PHASE ] [ scale <ベクトル> ] [ rotate <ベクトル> ] [ translate <ベクトル> ] } (訳注:ハローのサンプルはpov3demo\haloディレクトリにある。 attenua1.pov:さまざまなハロー attenuat.pov:減衰ハロー cloud.pov:雲 cloud2.pov:海に沈む夕日 dust.pov:ダストハロータイプ2 emit1.pov:さまざまな密度関数とマッピングタイプの放射ハロー emit2.pov:さまざまなカラーマップの放射ハロー。線形密度関数で球状マッピング emitting.pov:動乱を加えた放射ハロー glow.pov:動乱を加えたグローイングハロー haze.pov:霞 multiple.pov:複数のハロー planeth1.pov:惑星1 planeth2.pov:惑星2 steams.pov:蒸気 ) 7.6.4.1 ハローマッピング(Halo Mapping) 先に述べたように、実際の粒子分布とハローの外観はたくさんのパラメータによって影響される。ハローの計算の間実行されるステップが、下記に説明されるだろう。様々なハローのキーワードがその計算に影響することも気づいて欲しい。 1. 光線に沿った現在のサンプリング位置に依存して、ハローコンテナオブジェクト内の点 P(座標 x、y、z)が計算される。実際の位置はjitterキーワードとサンプルの数、anti-aliasing(aa_level と aa_threshold)の使用に影響される。 2. (現在の)ハローの変換を用いて、点 P は点 Q に変換される。ここですべての局所的なハロー変換、つまり(現在の)ハロー構文の中で指定されたすべての変換が作用する。 3. 点 Q に動乱(Turbulence)が加えられる。動乱の量はturbulenceキーワードで与えられる。動乱の計算はoctaves, omega および lambda キーワードに影響される。 4. 指定された密度マッピングに依存して半径 r が計算される。( planar_mapping, spherical_mapping, cylindrical_mapping, box_mapping)。その半径は0から1までの範囲にクリッピングされる。つまり、0 <= r <= 1。 5. 密度 d が半径 rから密度関数とmax_valueで与えられる最大値を用いて計算される( constant, linear, cubic, poly) 6. 密度 d は最初にfrequency値で掛けられphase値に加えられ、color_mapからカラーを得るために使う前に0 から 1 の範囲に切り取られる。もしattenuatingハローが使われた場合、その色は各サンプルの色の和ではなく、光線に沿った全密度から決定される。 ハローコンテナオブジェクト内部のそれぞれのサンプル点のために、光線に沿ってすべてのステップが繰り返される。ステップ2から6まではハローコンテナオブジェクトに付加されたすべてのハローに対して繰り返される。 有限の粒子分布つまり有限領域の外側でゼロになる粒子分布を得るために有限密度マッピングと有限密度関数が使われなければならないということに留意する必要がある。 有限密度マッピングは有限領域の外側では定数値1を与える。ボックスおよび球形マッピングだけが有限マッピングタイプである。 有限密度関数は1以上のすべてのパラメータの値に対してゼロになる(負のパラメータ値はない)。唯一の無限密度関数は定数関数である。 有限粒子分布はきわめて便利である。なぜならそれらはつねにハローコンテナオブジェクトの内部にとどまるように変換される。粒子がコンテナオブジェクトから去れば、それらは見えなくなり、表面における密度の不連続性のためコンテナオブジェクトの表面は見えるようになる。 7.6.4.2 複数のハロー(Multiple halo) 一つのコンテナオブジェクトの内部に複数のハローを置くことは可能である。これは単に以下のようにコンテナオブジェクト構文の内側に複数のハロー構文を置くだけでよい: sphere { 0, 1 pigment { Clear } halo { here comes halo nr. 1 } halo { here comes halo nr. 2 } halo { here comes halo nr. 3 } ... } それぞれのハローの効果は加えられる、これは実際CSG結合(union)操作と同じである。 あなたは現在複数の減衰(attenuating)ハローでは最後のハローだけがカラーマップを使用できることに注意すべきである。複数の減衰ハローにそれぞれのカラーマップを用いることは可能ではない。 7.6.4.3 ハローのタイプ(Halo Type) ハローのタイプは以下の相互に排他的なキーワードの一つで定義される(もし複数が指定された場合は最後のものが使われる)。デフォルトは減衰(attenuating)である。 halo { attenuating | emitting | glowing | dust } ハローのタイプは光がコンテナオブジェクト内部の粒子とどのように影響し合うかを決める。光の相互作用の二つの基本的な種類がある: 自分で光る(self-illuminated)のと照らされる(illuminated)ものである。最初のタイプは減衰(attenuating)、放射(emitting)および白熱(glowing)効果を含み、ダスト(dust)効果は2番目のタイプである。 7.6.4.3.1 減衰(Attenuating) 減衰ハロー(attenuating halo)はそれを通過する光を吸収するだけであり、光線に沿った粒子密度を累積することによりレンダリングされる。総ハローカラーは総累積密度と指定されたカラーマップから決められる。(カラーマップに関する詳細はセクション「ハローカラーマップ」を見て下さい)。バックグラウンドライト(背景光)、つまりハローを通過する光は総密度により減衰させられ、最終の色を得るために総ハローカラーに加えられる。 最終的な色はシングルボリュームの要素に透明度に依存しないで光線に沿った総透明度に依存するので、このモデルは粒子分布を高いアルベド※(albedo)でレンダリングするのに適している。ある粒子のアルベドは入ってくる光の量に関係してこの粒子によって四方八方に拡散される光の量で与えられる。もし粒子が光を吸収しないのならばアルベドはゼロである。 (※訳注:アルベド[albedo]は天体で外部からの入射光の強さに対する反射光の強さの比をいう。地面や雲などによる散乱も反射に含める。一般に天体の大気が多いほどアルベドが大きくなる。) 雲と蒸気は十分な動乱(turbulence)を加えることにより本当にリアルにレンダリングされる2つのこの効果である。 7.6.4.3.2 ダスト(Dust:ちり、ほこり) ダストハローは光を放射しない粒子からなる。それらは入ってくる光を反射および吸収するだけである。その構文は: halo { dust [ dust_type DUST_TYPE ] [ eccentricity ECCENTRICITY ] } 光線がダストを通過して進行するにつれ、光源から来るすべての光は累積され、ダストタイプとカレントのダスト密度によって拡散させられる。この光の累積は閉塞(occlusion)に対する検査を含んでいるので、他のオブジェクトはダストの中に影を投げかけることが可能である。 セクション「大気」の大気(atmosphere )で使われているものと同じ拡散タイプがダストとともに使える(デフォルトのタイプは等方性(isotropic)拡散である)。それらは: #declare ISOTROPIC_SCATTERING = 1 #declare MIE_HAZY_SCATTERING = 2 #declare MIE_MURKY_SCATTERING = 3 #declare RAYLEIGH_SCATTERING = 4 #declare HENYEY_GREENSTEIN_SCATTERING = 5 Henyey-Greenstein関数は大気に関するセクションで記述されている付加的なパラメータeccentricityを必要とする。このキーワードはダストタイプ5のHenyey-Greenstein散乱に適用されるだけである。 7.6.4.3.3 放射(Emitting) 放射ハロー(Emitting halo)は光を放射するだけである。 すべての粒子は光を放射する小さな光源である。この光は非常に小さいものと仮定されているので他の粒子によって減衰させられない。 光線が放射ハローの密度フィールドを通って移動するにつれ、各体積要素内の粒子の色とそれらの微分透明度(differential transparency)はカラーマップから決定される。これらの強度(intensities)は、密度フィールドの合計カラー(total color)を得るために累積される。この合計強度は、ハローを通り抜けている光に付け加えられる。背景光は、ハローの合計密度によって弱められる。 放射された光は弱めれれないので、それは炎、爆発、光のビームなどをモデル化するために使われる。よく適したカラーマップを選ぶことによって、それらの効果を高度なリアリズムでレンダリングすることができる。 炎は、平面(planar)マッピングを用いて、最もよくモデル化される。球形のマッピングと高いturbulence(動乱)値は、爆発（周期的なカラーマップと、1より大きい周波数を用いると最高である）を作成するために用いることができる。 放射ハローはそれらが小さな、光を放射する粒子から作られているけれども、他のオブジェクトの上にいかなる光も光源のようには投げかけない。それらに実際に光を放射させるためには、何百、何千もの小さな光源を使わなければならない。このことはそれを役に立たなくする程にトレーシングを遅くする。 7.6.4.3.4 グローイング(Glowing:白熱している) グローイングハローは放射ハローと似ている。その違いは粒子から放射される光が他の粒子によって減衰させられることである。これは減衰と放射モデルの組合せとみなすことができる。 7.6.4.4 密度マッピング(Density Mapping) 密度マッピングは空間の点を、線形の、0と1.0の間の一次元の区間にマップするのに用いられ、そして三次元の粒子分布の外観を記述する。それぞれのマッピングのタイプは以下によって指定される: halo { planar_mapping | spherical_mapping | cylindrical_mapping | box_mapping } デフォルトのマッピングタイプは平面マッピング(planar mapping)である。 マッピングはワールド座標系の原点に関して起こるので、以下の規則を常に心に保持しなければならない:ハローコンテナオブジェクトは、中心が原点にある単位サイズのオブジェクトであるべきである。それらは後に個々の要求に都合が良いように変換することができる。 それぞれのマッピングタイプが続くセクションでより詳しく説明される。 7.6.4.4.1 ボックスマッピング(Box Mapping) ボックスマッピングは箱形の粒子分布を作成するために使うことができる。マッピングは以下の式で与えられるように、それぞれの座標の絶対値の最大値をとって計算される: r(x, y, z) = max(abs(x), abs(y), abs(z)) 7.6.4.4.2 円筒マッピング(Cylindrical Mapping) ｙ−軸からの距離r(x,y,z)を与える r(x, y, z) = sqrt(x*x + z*z) が間隔値を得るために使われる。1より大きな値は1に切り下げられる。 7.6.4.4.3 平面マッピング(Planar Mapping) x-z-平面からの距離 r(x,y,z)を与える r(x, y, z) = abs(y) が間隔値を得るために使われる。1より大きな値は1に切り下げられる。 7.6.4.4.4 Spherical Mapping 原点からの距離r(x,y,z)は r(x, y, z) = sqrt(x*x + y*y + z*z) で与えられ、間隔値を得るために使われる。1より大きな値は1に切り下げられる。 7.6.4.5 密度関数(Density Function) 密度関数は、密度マッピングから生じた線形の、一次元の間隔から実際の密度値がどのように計算されるかを決める。 密度関数は以下のキーワードで指定される: halo { [ constant | linear | cubic | poly ] [ max_value 最大値 ] [ exponent 指数 ] } exponent(指数)キーワードはpoly(多項式)密度関数と一緒にだけ使われる。 個々の関数f(r)は続くセクションで記述される。それらはすべて密度マッピングから計算された値r(x,y,z)を0から(キーワードmax_valueで指定された)"最大値"の範囲の適当な密度にマップする。 7.6.4.5.1 定数(Constant) 定数(constant)関数は間隔値と密度マッピングのタイプに関係なく一定の値の最大値を与える。それはつまらない公式 f(r) = "最大値" で計算される。 図 定数密度関数。 定数密度関数は、コンテナオブジェクトによって束縛されるだけの一定の粒子分布を作成するために用いることができる。 7.6.4.5.2 線形(Linear) 線形(linear)はr=0の最大値からr=1のゼロまで減少し、線形密度関数から作成される。それは: f(r) = 最大値 * (1 - r) で与えられる。 図() 線形密度関数 7.6.4.5.3 三次式(Cubic) 三次式(cubic)関数はr=0の最大値"最大値"とr=1の0の間の滑らかな混合を与える。それは: f(r) = 最大値 * (2 * r - 3) * r * r + 1 で与えられる。 図　三次密度関数。 7.6.4.5.4 多項式(Poly) 多項式関数は、密度関数の豊富な多様性を得るために用いられる。すべてはr=0で最大値"最大値"をr=1で最小値を持つ。それは f(r) = 最大値 * (1 - r) ^ 指数 で与えられる。 図 種々の指数値に対する多項式の密度関数。 指数はexponentキーワードで与えられる。指数=0の場合は線形の減退(falloff)を得る。 7.6.4.6 ハローカラーマップ(Halo Color Map) 密度f(r)は、0から最大値の範囲で, 光線が密度フィールドを通って進行する間それぞれの体積要素に対してカラーと微分透明度を得るためにカラーマップ上にマップされる(最終的な減衰ハローの色は合計密度から計算される;セクション「ハローマッピング」およびセクション「減衰(Attenuating)」を参照)。微分透明度はf(r)のそれぞれの値に対してどのくらいの合計の不透明(opacity)が増加するか(あるいは減少するか)決める。 カラーマップは以下で指定される: halo { [ colour_map カラーマップ ] } 微分半透明性(differential translucency)はマップのカラーエントリの透過チャネルに保存される。簡単な例が以下で与えられる colour_map { [0 rgbt<1, 1, 1, 1>] [1 rgbt<1, 1, 1, 0>] } この例では低い密度の(小さい f(r))の領域は半透明で(大きな微分半透明性の1=100%)あり、高密度(大きい f(r)) は不透明体になる(0=0% の小さい微分半透明性)。負の透過(transmittance)値は非常に高密度のフィールドを作るのに使えるということを記憶にとどめておいてください。 ダストハローの場合、カラーマップ中のカラーのフィルタチャンネルは対応するカラーマップエントリによりフィルタされる光の量を指定するために使われる。すべての他のハロータイプに対しては、フィルタ(filter)値は無視される。 7.6.4.7 ハローのサンプリング(Halo Sampling) ハロー効果は、密度フィールドを通して光線に沿って進行することによって計算される。サンプルは、離散的なステップで密度フィールドからとられ、カラーマップと他のすべてのパラメータに従って評価される。すべての体積要素の効果が総効果を得るために累積される。 以下に続くパラメータは、サンプリング処理を調整するために用いられる: halo { [ samples サンプル ] [ aa_level AA_レベル ] [ aa_threshold AA_しきい値 ] [ jitter ジッタ ] } 7.6.4.7.1 サンプルの数(Number of Samples) ハローのコンテナオブジェクト内部の光線に沿ってとられるサンプルはsamplesキーワードで指定される。samplesの数が大きいほどより高い密度フィールドがサンプルされより正確になるが結果は遅くなるだろう。 デフォルトのsamplesの数は10である。これは動乱(turbulence)を用いない簡単な密度フィールドでは十分である。 高いturbulence値とダストハローは通常エイリアシングするアーチファクト(不自然なもの)を避けるために大きな値のサンプル(samples)が必要である。 7.6.4.7.2 スーパーサンプリング(Super-Sampling) サンプリングは(セクション「大気」における大気のサンプリングのように)エイリアスする傾向がある。エイリアスアーチファクトを減らすための可能な方法の一つのは、スーパーサンプリング(super-sampling)を用いることである。もし、2つの隣り合うサンプルがあまりに異なる場合、両者の間に付加的なサンプリングがなされる。このプロセスはサンプルの値が互いに接近するか、AA_LEVELで与えられた最大の再帰レベルに到達するまで再帰的になされる。スーパサンプリングをやめる(kick in)しきい値はAA_THRESHOLDで与えられる。 デフォルトでスーパーサンプリングは使われない。AA_THRESHOLDとAA_LEVELのデフォルトの値はそれぞれ 0.3 と 3 である。 7.6.4.7.3 ジッタ(Jitter) ジッタ(Jitter)はサンプリング位置にいくらかのノイズを導入するために使うことができる。 これはイメージ中のノイズが増加するのを犠牲にして、エイリアシングアーチファクト減らすのを助けるだろう。人間の視覚システムは規則的なパターンよりもより多くのノイズを許すので、これはそれほど問題ではない。 デフォルトでジッタリング(jittering)は使われない。その値は1.0より小さくなければならない。 7.6.4.8 ハロー修飾子(Halo Modifiers) 本セクションではすべての一般的なハロー修飾子をカバーする。それらは: halo { [ turbulence <動乱> ] [ octaves オクターブ ] [ omega オメガ ] [ lambda ラムダ ] [ frequency 周波数 ] [ phase 位相 ] [ scale <ベクトル> ] [ rotate <ベクトル> ] [ translate <ベクトル> ] } 7.6.4.8.1 周波数修飾子(Frequency Modifier) frequency(周波数)パラメータは密度間隔(density interval)が自分自身にオーバーラップする回数を調整する。つまり、それがカラーマップ上にマップされる前の、0.0から1.0までの範囲である。これを行うための公式は: f_new(r) = (f(r) * 周波数 + 位相) modulo 1.0 (訳注:moduloは「法とする」の意であるが整数除算の剰余と考えて良い) 7.6.4.8.2 位相修飾子(Phase Modifier) phase(位相)パラメータは密度フィールドのそれ自身へのマッピングを開始するオフセットを決める。 位相がどのように使われるかについては上のセクションの公式を見て欲しい。 7.6.4.8.3 変換修飾子(Transformation Modifiers) ハローはrotate、scaleおよびtranslateキーワードを用いて変換することができる。けれども密度フィールドをコンテナオブジェクトの外へ移動しないように注意しなければならない。 7.6.5 特殊テクスチャ(Special Textures) 特殊テクスチャ(Special textures)は複数のテクスチャから作られた複雑なテクスチャである。その成分のテクスチャはプレインテクスチャ(plain texture)でも特殊テクスチャから作られたものでも良い。プレインテクスチャはたった一つのピグメント、法線、および仕上げ構文(それといくつかのハロー構文)しか持たない。ピグメントマップを伴うピグメントはまだ一つのピグメントであり、したがってそれは法線マップ構文を持つ法線のようにプレインテクスチャと考えられる。 特殊テクスチャは混合を指定するためのtexture_mapキーワードかあるいはテクスチャパターンいずれかを用いるか、あるいはイメージマップと同じように(material_mapキーワードで指定される)マテリアルマップ(material map)と呼ばれるビットマップを用いる。 特殊テクスチャの使用法に関しては制限がある。特殊テクスチャはデフォルトテクスチャとして使ってはならない(セクション「デフォルト命令(Default Directive)」を見なさい)。特殊テクスチャに含まれるテクスチャとして任意の階層テクスチャを使っても良いけれども、スペシャルテクスチャは階層化テクスチャ(layered texture)の層(layer)としては使えない。 7.6.5.1 テクスチャマップ(Texture Maps) カラーマップあるいはピグメントマップを用いた混合色の指定に加えて、テクスチャマップ(texture_map)を用いてテクスチャの混合を作成できる。テクスチャマップの指定は、それぞれのマップエントリにテクスチャを指定することを除きピグメントマップと同じである。 テクスチャマップは以下のように指定される... texture{ パターンタイプ texture_map { [ 数値_1 テクスチャ本体_1] [ 数値_2 テクスチャ本体_2] [ 数値_3 テクスチャ本体_3] ... } テクスチャ修飾子... } ここで 数値_1、数値_2、...は0.0から1.0の範囲に含まれる浮動小数点数値である。"テクスチャ本体"はtexture {... }構文の内部に通常現れるものなら何でも良いが、textureキーワードと{}括弧は不要である。注意:[]括弧は実際の構文の一部である。それらは選択可能な部分を示す表記上の記号ではない。この括弧はマップの各エントリを囲む。マップ内には2から256のエントリが可能である。 例えば: texture { gradient x //これがパターンタイプ texture_map { [0.3 pigment{Red} finish{phong 1}] [0.3 T_Wood11] //これはテクスチャ識別子 [0.6 T_Wood11] [0.9 pigment{DMFWood4} finish{Shiny}] } } このgradient x 関数が0.0から0.3までの値を返す場合、赤いハイライティングされたテクスチャが使われる。0.3から0.6の場合テクスチャ識別子T_Wood11が使われる。0.6から0.9まではT_Wood11と光る(shiny) DMFWood4の混合が使われる。0.9から上では光る木材(shiny wood)だけが使われる。 テクスチャマップはあなたが望む任意のレベルの複雑さでいれ子にすることができる。マップ内のテクスチャはカラーマップあるいはテクスチャマップかあなたが望む任意のタイプのテクスチャを持っても良い。 テクスチャマップの混合領域はそれらのエントリ内の寄与する両テクスチャの完全な計算とそれから見かけの色の線形補間により動作する。これは反射、屈折および照明の計算が各点で2度計算されることを意味する。これはピグメントが計算され、それから法線、反射、屈折および照明が各点について1度計算されるプレインテクスチャ内でのピグメントマップ及び法線マップと対照的である。 チェッカー(checker)、六角形(hexagon)、煉瓦(brick)のようなブロックパターンを含むすべてのテクスチャがまた使える。例えば... texture { checker texture { T_Wood12 scale.8 } texture { pigment { White_Marble } finish { Shiny } scale.5 } } } 注意:ブロックパターンの場合texture {... }の囲いはテクスチャ情報のまわりに必要である。また、この構文(文法)は階層化テクスチャの使用を禁止するが、あなたは階層化テクスチャに対するテクスチャ識別子を宣言し、その識別子を参照することによりその関係の作業をすることができる。 テクスチャマップは平均パターン(average pattern)タイプのためにも使われる。詳しくは"Average"を見て下さい。 7.6.5.2 タイル(Tiles) 初期のバージョンのPOV-Rayにはタイルテクスチャ(tiles texture)と呼ばれるテクスチャのチェッカーパターンを作る特殊テクスチャがあった。 これはまだ後方互換性のためにサポートされてるけれども、タイルテクスチャの代わりにセクション「テクスチャマップ」で説明されているチェッカー(checker)ブロックテクスチャパターンを使うべきである。 7.6.5.3 マテリアルマップ(Material Maps) マテリアルマップ(material map)特殊テクスチャはイメージマップのコンセプトを単色だくでなくすべてのテクスチャに適用するするために拡張する。マテリアルマップは2-D ビットマップ・テクスチャパターンをあなたの3-Dオブジェクトの回りに貼り付ける。 イメージマップのように単色のイメージを形状の上に置く代わりに、その点におけるイメージの色あるいはインデックスに基づいてすべてのテクスチャが指定される。あなたは通常のカラーパレットではなくテクスチャパレットのように、用いられるテクスチャのリストを指定しなければならない。 GIF、一部のPNGおよびTGA画像のようなマップされたファイル形式とともに用いられた場合、ピクセルのインデックスがあなたが与えたテクスチャへのインデックスとして用いられる。一部のPNGやTGAのようなマップされていないファイル形式に対しては0-255範囲の赤成分の8ビットの値がインデックスとして用いられる。 あるピクセルのインデックスがリスト内のテクスチャの数よりも大きければそのインデックスはNの剰余がとられる。ここでNはあなたのテクスチャのリストの長さである。 7.6.5.3.1 マテリアルマップを指定する(Specifying a Material Map) マテリアルマップ(material map)の構文は... texture { material_map { ファイルタイプ "filename" ビットマップ修飾子... texture {..}. // 最初のテクスチャはインデックス0に対して用いられる texture {..}. // 2番目のテクスチャはインデックス1に対して用いられる texture {..}. // 3番目のテクスチャはインデックス2に対して用いられる texture {..}. // 4番目のテクスチャはインデックス3に対して用いられる // その他、たくさんの使用のために。 } 変換... } ここで"ファイルタイプ"は以下のキーワードの一つである。gif、tga、iff、ppm、pgm、pngあるいはsys。これに任意の有効な文字列式を用いたファイル名が続く。いくつかのオプションの修飾子がこのファイル指定に続いても良い。この修飾子は以下に記述する。注意:初期のバージョンのPOV-Rayでは"ファイルタイプ"以前にいくつかの識別子を許したが、その構文はここで記述された構文に賛成して段階的に排除されている。 マテリアルマップ(material_map)構文で指定されたファイル名はホーム(カレント)ディレクトリを最初に探され、見つからなければ、+LスイッチあるいはLibrary_Pathオプションで指定された任意のディレクトリを探される。このことは、別のサブディレクトリにあなたのすべてのマテリアルマップファイルを保有して、ライブラリパスをそれらに指定するのを容易にする。注意:オペレーティングシステムのデフォルトパスはあなたがそれもLibrary_Pathに指定しない限り探されない。 デフォルトで、マテリアル(material)はx-y-平面にマップされる。 マテリアルはまるでスライドプロジェクタが-z方向のどこかにあるかのようにオブジェクトに投影される。マテリアルはビットマップのピクセル数のオリジナルサイズによらず、(x,y)座標の(0,0)から(1,1)までの正方形領域を正確に満たす。あなたがこのデフォルトを変更したければ、あなたは必要に応じてオブジェクトの表面にマップするためのテクスチャを平行移動、回転あるいは拡大縮小しても良い。 ファイル名にはオプションで1つあるいはそれ以上のビットマップ修飾子が続く。他の詳細のために「ビットマップ修飾子」を見て下さい。 material_map構文の後ろの、テクスチャ構文内にあなたは正当なテクスチャ修飾子を適用しても良い。注意:マテリアルマップの外側のテクスチャに他のピグメント、法線、仕上げあるいはハローが加えられてはならない。以下の例は間違いである: texture { material_map { gif "matmap.gif" texture {T1} texture {T2} texture {T3} } finish {phong 1.0} } この仕上げは、それぞれのテクスチャに個別に付け加えられなければならない。 注意:初期のバージョンのPOV-Rayはそのような指定を許しが、それらは無視された。上の文法上の制約は様々なバグ修正のために必要であった。このことはいくつかのマテリアルマップを使っているPOV-Ray 1.0のシーンには、バージョン互換モードでは自動的にはなされない僅かな修正が必要であるということを意味する。 あるイメージに特定のインデックス値が使われていない場合、ダミーのテクスチャを与えることが必要かもしれない。ペイントプログラムあるいは他のユーティリティを使うために、どのようにテクスチャリストを配置するか決めるためにマップファイルのパレットを調べることが必要である。 マテリアルマップテクスチャ内のテクスチャは階層化しても良いが、マテリアルマップテクスチャは階層化テクスチャの一部としては機能しない。階層化テクスチャをマテリアルマップ内で使うためには、あなたはそれをテクスチャ識別子として宣言し、それをテクスチャリスト内で呼び出さなければならない。 7.6.6 階層化テクスチャ(Layered Textures) 階層化されたテクスチャ(layered textures)を用いたいろいろな特殊効果を作成することが可能である。階層化テクスチャは部分的に透明なあるいはより複雑なテクスチャを作るために他の上に重なるいくつかのテクスチャからなる。いくつかのテクスチャの組み合わせである一つのテクスチャの外観を作るために、様々なテクスチャ層が透明な部分を通して見える。 あなたは二つまたはそれ以上のテクスチャを、あるものを他の右に並べることによって階層化テクスチャを作成する。リストされた最後のテクスチャは最上層になり、並べられた最初のは最下層になる。最下層以外の階層化テクスチャ内のすべてのテクスチャはいくらかの透明度を持たねばならない。例えば: object { My_Object texture {T1} // 最下層r texture {T2} // 一部透明な層 texture {T3} // 最上位の一部透明な層 } この例でT2は、T3が透明な部分だけに見え、T1は、T2とT3が透明な部分だけに見える。 下層のカラーは上層によりフィルタリングされるが、結果は、一連の透明な表面のようにように正確には見えない。もしあなたがそれぞれにテクスチャが適用されたたくさんの表面を持つならば、光は2度フィルタされる:一度は下部の層がフィルタされた光に照らされるように、入る途中で、一度は出る途中である。階層化テクスチャは入る途中で照明をフィルタしない。照明の計算の他の部分は違ったふうにうまく働く。結果はすばらしく、ファンタスチックに見えるテクスチャを与えるが、複数の表面とは単純に異なる。いくつかの壮麗な階層化されたテクスチャのために標準インクルードファイルディレクトリ内のstones.incを見て下さい。 注意:階層化テクスチャはピグメント、法線あるいは仕上げ構文を囲むtexture {... }を使わなければならない。複数のピグメント、法線あるいは仕上げ構文をテクスチャ構文の内側に置くことなしで使わないで下さい。 階層化テクスチャを宣言しても良い。例えば #declare Layered_Examp = texture {T1} texture {T2} texture {T3} は以下のように呼び出される: object { My_Object texture { Layer_Examp // 任意のピグメント、法線あるいは仕上げをここにおくと // 最下層だけが修正される。 } } もしあなたが階層化テクスチャをチェッカー(checker)、六角形(hexagon)あるいは煉瓦(brick)のようなブロックパターン内あるいはマテリアルマップで使いたい場合、あなたは最初にそれを宣言し、それを一つのテクスチャ構文の中で参照しなければならない。特殊テクスチャは階層化テクスチャ内の層としては使えないが、階層化テクスチャを特殊テクスチャに含まれる任意のテクスチャのように使っても良い。 7.6.7 パターン(Patterns:模様) (訳注:すべてのパターンのサンプルはディレクトリpov3demo\surfacesにある。 CRACKLE .POV ONION .POV SPIRAL2B.POV DENTS .POV PIGAVG .POV SPOTTED .POV AGATE .POV GRADIENT.POV PIGMAP .POV TXTRAVG .POV ATTEN1 .POV GRANITE .POV PIGNORM .INC TXTRMAP .POV ATTEN2 .POV HEXAGON .POV QUILT2 .POV WARP1 .POV BLKHOLE .POV IRID .POV QUILTED .POV WARP2 .POV BOZO .POV IRIDWLEN.POV RADIAL .POV WAVENORM.POV BRICK .POV LEOPARD .POV RGBT .POV WAVEPIG .POV BRICK2 .POV MANDEL .POV RGBT2 .POV WAVES .POV BUMPS .POV MARBLE .POV RIPPLES .POV WOOD .POV CAUSTIC1.POV MT-BLOB1.POV SLOPEMAP.POV WRINKLES.POV CAUSTIC2.POV MT-BLOB2.POV SPIRAL1 .POV CHECKER .POV MT-BLOB3.POV SPIRAL1A.POV COLAMB1 .POV NORMAVG .POV SPIRAL1B.POV COLMIR1 .POV NORMMAP .POV SPIRAL2 .POV CRACK1 .POV NUMWAVES.POV SPIRAL2A.POV ATTEN?.POVは半透明オブジェクトによる減衰、COLAMB1.POVは色を付けた環境光、COLMIR1 .POVは色の付いた反射、RGBT?.POVは透過色、TXTRAVG .POVは平均化したテクスチャ等のサンプルである。他はファイル名から概ね予想が付くと思う。 ) POV-Rayはカラー(color)、凹凸(bumpiness)および他の表面の特性を定義するために、三次元ソリッドテクスチャリングと呼ばれる方法を使う。あなたは、パターン(pattern)を指定することによって、テクスチャが表面の上で変化する方法を指定する。パターンはピグメント(pigments)、法線(normals)およびテクスチャマップ(texture maps)で用いられる。 POV-Rayのすべてのパターンは3次元である。空間内のすべての点に対して、それぞれのパターンは一意の値を持つ。パターンはオブジェクトに壁紙を貼るようには表面のまわりを包まない。パターンは3dで存在し、オブジェクトは木材や石の中実なかたまりからオブジェクトを彫刻するように、それから刻まれる。 木のブロックを考えなさい。それは木材の年輪である同心円筒の淡いあるいは暗いバンドを持つ。そのブロックの端では、あなたはそれらの同心円をみるだろう。その長さに沿って、木目(veins)の線を見る。しかし、このパターンはブロックの全体にわたって存在する。あなたが木材を切るか、刻むならば、それは内部のパターンを表す。同様に、タマネギ(onion)はあなたがそれを切り取るとき見える同心球から成る。大理石(Marble stone)はそれが固まって岩になった色の付いた沈殿物の波状の層からなる。 これらのソリッドパターンは、数学的関数を用いてシミュレートすることができる。花こう岩(granite)かバンプ(bumps)とくぼみ(dents)のような他のランダムなパターンは、乱数システムとノイズ関数を用いて生成することができる。 それぞれ場合、表面上の点のx, y, z座標は、浮動小数点数値を返すいくつかの数学的関数を計算するために用いられる。カラーマップあるいはピグメントマップとともに用いられた場合、その値は用いられるピグメントのカラーを調べる。法線(normal)構文ではパターン関数の結果はでこぼこな外観を与えるために表面法線ベクトルを変更するかかき乱す。テクスチャマップで使われると、その関数の結果はすべてのテクスチャのどれが組み合わせが使われるかを決める。 以下のセクションではそれぞれのパターンを述べる。パターンの使用法についてはセクション「ピグメント」および「法線」を見て下さい。 7.6.7.1 Agate(めのう) (図 Agateパターン) agate(めのう)パターンはmarbleと同様の帯状の模様であるが、伝統的な動乱(turbulence) と異なる専用の組み込み動乱関数を用いる。伝統的な動乱もまた用いることができるが、agateはすでに非常に乱れているので一般にそれは必要でない。あなたは組み込み動乱の量を浮動小数点数値が続くagate_turbキーワードを追加して制御しても良い。例えば: pigment { agate agate_turb 0.5 color_map { ... } } agateパターンはデフォルトでramp_waveウェーブタイプ(wave type)を使うが、任意のウェーブタイプが使用できる。このパターンはカラーマップ、ピグメントマップ、法線マップおよびテクスチャマップとともに用いられても良い。 7.6.7.2 Average(平均) 技術的にはaverageはパターンタイプではないが、その構文が他のパターンと同じなのでここにリストする。典型的には、パターンタイプはピグメントマップあるいは法線マップからどのようにカラーあるいは法線を選ぶかを指定するけれども、averageはあなたの指定したすべてのパターンの平均をとるようにPOV-Rayに知らせる。Averageはもともとは、同じ表面に複数の法線パターンを指定するための方法として、法線構文で法線マップとともに使うために設計された。しかしながら、averageはピグメント構文でピグメントマップとともにあるいはテクスチャ構文でテクスチャマップとともにカラーを平均するためにも使用することができる。 ピグメントとともに使う場合、その構文は: pigment { average pigment_map { [重み_1 ピグメント本体_1] [重み_2 ピグメント本体_2] ... [重み_n ピグメント本体_n] } ピグメント修飾子 } 同様に、あなたはテクスチャ構文の中でテクスチャマップを使っても良い。すべてのテクスチャは完全に計算される。結果として生ずるカラーは重み付けされ平均される。 法線構文の中で法線マップとともに使われる場合、オリジナルの表面法線の複数のコピーが作成され、それぞれのパターンでかき乱される。かき乱された法線はそれから重み付けされ、加えられ、正規化される。 さらなる情報は、セクション「ピグメントマップ」、「法線マップ」および「テクスチャマップ」を見て下さい。 7.6.7.3 Bozo(ボウゾウ:野郎) (図 Bozoパターン) bozoパターンは非常に滑らかなランダムノイズ関数であり、伝統的にいくらかの動乱(turbulence)とともに雲を作成するのに使われる。spotted(斑点)パターンはbozoと同一であるが、初期のバージョンのPOV-Rayではspottedは動乱を加えることが許されなかった。動乱(Turbulence)は、現在はすべてのパターンに加えることができるので、これらは重複しているが、後方互換性のため両方とも残してある。法線構文を除く任意の場所で、bumps(でこぼこ)パターンもまたbozoと同一である。法線として使われる場合は、類似のノイズ関数で法線をかき乱すためにわずかに異なる方法を用いる。 bozoノイズ関数は以下の性質を持つ: 1. 3D空間上に定義されている。すなわち x, y, および zをとりそこにノイズ値を返す。 2. もし2点が遠く離れている場合、それらの点のノイズ値は相対的にランダムである。 3. もし2点は互いに接近している場合、それらの点のノイズ値は互いに接近している。 あなたは大きな部屋と0.0から1.0までの範囲の温度計を持っているとしてこれを視覚化することができる。部屋のそれぞれの点はある温度を持つ。遠く離れた点は相対的にランダムな温度である。互いに近い点では近い温度になる。われわれが部屋の中を移動するにつれ温度は滑らかにしかしランダムに変化する。 この部屋に芸術家と一緒にオブジェクトを置こう。芸術家はオブジェクト上のそれぞれの点で温度を測り、その温度によって異なる色をその点に塗る。何を得るか? POV-Rayのbozoテクスチャである。 bozoパターンはramp_waveウェーブタイプ(wave type)をデフォルトで使うが、任意のウェーブタイプが使用できる。このパターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapとともに用いても良い. 7.6.7.4 Brick(煉瓦、ブリック) (図 Brickパターン) brickパターンは煉瓦模様を生成する。煉瓦はすべての違う列で半分の煉瓦の長さでx-およびz-方向にオフセットされる。モルタルの層がそれぞれの煉瓦を囲む。 構文は以下に与えられる pigment { brick カラー_1, カラー_2 brick_size ベクトル mortar 浮動小数点数 } ここで カラー_1 はモルタルのカラーでカラー_2 煉瓦自身のカラーである。もしカラーが指定されないと、デフォルトの深い赤と暗いグレイが使われる。煉瓦とモルタル一緒のデフォルトサイズは<8, 3, 4.5>単位である。デフォルトのモルタル厚さは0.5単位である。これらの値はオプショナルなbrick_size および mortar パターン修飾子を用いて変更できる。また、カラーの場所にピグメント構文を使っても良い。例えば: pigment { brick pigment{Jade}, pigment{Black_Marble} } 法線とともに使う場合の構文は normal { brick BUMP_FLOAT } ここで BUMP_FLOAT はオプショナルなバンプサイズ(bump size)浮動小数点値である。また、完全な法線構文を用いても良い。例えば: normal { brick normal{bumps 0.2}, normal{granite 0.3} } テクスチャとともに使う場合の構文は texture { brick texture{T_Gold_1A}, texture{Stone12} } これはウェーブタイプ、カラーマップあるいは傾斜マップ修飾子の使えないブロックパターンである。 7.6.7.5 Bumps(でこぼこ、バンプ) (図 Bumpsパターン) bumpsパターンはもともとは法線パターンだけで使うために設計された。それは大きく拡大された場合にはうねる丘に、小さく縮小したときにはでこぼこのあるオレンジの調子にみえる非常に滑らかな、ランダムノイズ関数を用いる。大抵でこぼこは1単位離れている。 法線として使われる場合、bumpsは特殊な法線動揺関数(normal perturbation function)を使う。このことはこのbumpsパターンは法線構文の中では、法線マップ、傾斜マップあるいはウェーブタイプ修飾子と一緒には使えないことを意味する。 ピグメントパターンあるいはテクスチャパターンとして使うときは、このbumpsパターンはbozoあるいはspottedと同じであり、またnormal bumpsと同様であるが、ピグメントと比較した場合、ほとんどの法線にあるのとは同一ではない。このパターンはカラーマップ、ピグメントマップおよびテクスチャマップとともに使っても良い。 7.6.7.6 チェッカー(Checker、市松格子) (図 Checkerパターン) checkerパターンはカラー_1 と カラー_2 の交互の正方形からなるチェッカーパターンを作る。カラーが指定されない場合デフォルトの青と緑のカラーが使われる。 pigment { checker カラー_1, カラー_2 } チェッカーパターンは実際は1単位の大きさの一連の立方体である。2つの別の色の模型用粘土の立方体の集団を想像して下さい。交互にチェックパターンになる立方体の配置を想像し、色がまだずべての方向に交互になるようにそれらの層を層の上に積みなさい。最終的にあなたはより大きな立方体を得る。それぞれの側面のチェックのパターンはPOV-Ray のチェッカーパターンがボックスオブジェクトに適用されたときに作るものである。最後にその立方体を滑らかな球か他の形に彫刻されるまで切り取ることを想像して下さい。これが任意の種類のオブジェクトでチェッカーパターンが何に見えるかである。 あなたはカラーの場所にまたピグメント構文を使ってもよい。例えば: pigment { checker pigment{Jade}, pigment{Black_Marble} } 法線と共に使うときの構文は normal { checker BUMP_FLOAT } ここで BUMP_FLOAT はオプショナルなバンプサイズの浮動小数点数値である。完全な法線構文を指定しても良い。例えば: normal { checker normal{gradient x scale.2}, normal{gradient y scale.2} } テクスチャと共に使う場合の構文は... texture { checker texture{T_Wood_3A},texture{Stone12} } これはチェッカーを以前のバージョンのPOV-Rayの特殊タイルテクスチャの代わりのテクスチャパターンとして使う。あなたはまだタイル(tiles)を使っても良いが、将来のバージョンでは段階的に廃止になるかもしれないのでチェッカーテクスチャが最善である。 これはブロックパターンであり、ウェーブタイプ(wave types)、カラーマップ、傾斜マップ修飾子は使えない。 7.6.7.7 Crackle(細かいひび、クラックル) (図 Crackleパターン) crackleパターンはランダムにタイル貼りされた多角形の集合である。大きなスケールでturbulenceがない場合、非常に良い石の壁あるいは床を作成する。小さなスケールでturbulenceがない場合、非常に良い細かいひびの陶器の上薬を作成する。高いturbulenceを用いると、伝統的なmarble(大理石)の外見上の平行な層の問題を避ける良い大理石を作成する。 数学上は、集合crackle(p)=0は半ランダム点(semi random points)のフィールドの3Dボロノイ図(Voronoi diagram)で、crackle(p) < 0 はその集合からの最短経路に沿った距離である(ボロノイ図は、一そろいの共通の要素を持たない点の集合からのそれらの最も近い2つの隣接点から等距離の点の軌跡(locus)であり、泡の真ん中にとった石鹸の泡の中の膜のようである)。 crackleパターンはramp_wave ウェーブタイプをデフォルトで使うが、任意のウェーブタイプを使っても良い。このパターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapとともに用いても良い。 7.6.7.8 Dents(くぼみ、デンツ) (図 Dentsパターン) dents(くぼみ)パターンはもともとは法線パターンの一つとして用いるためだけに設計された。これはメタリックテクスチャ(metallic textures)とともに使うと特に面白いものである。 金属表面にハンマーで叩かれたくぼみのように見える感じを与える。通常の場合そのくぼみ(dents)はだいたい1単位離れている。 法線パターンとして用いられた場合、dentsは専用の法線動揺関数を使う。これはdentsパターンが法線構文の中で法線マップ、傾斜マップあるいはウェーブタイプ修飾子といっしょには使えないことを意味する。 ピグメントパターンあるいはテクスチャパターンとして使われた場合、dentsパターンは法線dentsと同様であるが、ピグメントと比較した場合ほとんどの法線と同一ではない。ピグメントあるいはテクスチャ構文で用いられた場合、dentsパターンはramp_waveウェーブタイプをデフォルトで用いるが、任意のウェーブタイプを用いて良い。このパターンはcolor_map、pigment_mapおよびtexture_mapとともに用いても良い。 7.6.7.9 Gradient(傾斜、勾配、グラジアント) (図 Gradientパターン) gradientパターンは傾斜模様である。これは以下のように指定される pigment {gradient ベクトル} ここで"ベクトル"はカラーが混合される方向を指すベクトルである。例えば pigment { gradient x } // あなたが"x"方向に沿って動くと // 色の帯が変化する。 は、互いに隣り合う色の層のように見える一連の滑らかな色の帯を生成する。x=0の点はカラーマップ中の最初の色である。x位置が増加するにつれx=1における最後の色まで滑らかに変化する。そして、再び最初から始め、x=2の最後の色まで徐々に変化する。xの負の値に対してパターンは逆になる。gradient y あるいは gradient z の使用は、色の混合を y- あるいは z-軸に沿ったものにする。任意のベクトルが使えるが、x、y およびzが最も一般的である。 法線パターンとして、gradientは鋸の歯あるいは傾斜した波の外観を与える。構文は normal { gradient ベクトル, BUMP_FLOAT} ここで、方向を与える<ベクトル>は必要なパラメータであるが、続くバンプサイズのBUMP_FLOATはオプションである。 このパターンはデフォルトでramp_waveウェーブタイプを用いるが、任意のウェーブタイプを用いても良い。このパターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapとともに用いても良い。 7.6.7.10 Granite(花崗岩) (図 Graniteパターン) このパターンは良い花崗岩パターンを与えるために単純な1/fフラクタルノイズ関数を用いる。このパターンはstones.inc内の独創的なカラーマップとともに華麗な階層化された石のテクスチャを作成するために使われる。 法線パターンとして、砂利道やざらざらした石のように見える非常にでこぼこな表面を作成する。 このパターンは、デフォルトでramp_waveウェーブタイプを用いるが、任意のウェーブタイプを用いてもよい。パターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapで用いても良い。 7.6.7.11 Hexagon(ヘキサゴン、六角形) (図 Hexagonパターン) hexagonパターンはx-y平面上の六角形の繰り返しパターンを生成するブロックパターンである。このインスタンス(instance)では六角形でy-軸に平行で、サンプルイメージに示したような束ねられた高いロッドを想像してください。3つの別々のカラーが以下のように指定される: pigment { hexagon カラー_1, カラー_2, カラー_3 } _____ / \ / C2 \_____ |\ / \ | \_____/ C3 \ | / \ /| / C1 \_____/ | |\ /| | | | \_____/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 図　hexagon(六角形)パターン。 3つのカラーがこの六角形のパターンで、"カラー_1"の六角形が原点に中心を置き、"カラー_2"が+z-方向で、"カラー_3"がいずれの側面にも繰り返される。六角形の各側面は1単位の長さである。カラーの六角形のロッドは無限に+y-および-y-方向に伸びる。カラーが指定されないとデフォルトの青、緑、赤のカラーが使われる。 また、カラーの場所にピグメント構文を使っても良い。例えば: pigment { hexagon pigment { Jade }, pigment { White_Marble }, pigment { Black_Marble } } 法線で使う場合の構文は normal { hexagon BUMP_FLOAT } ここでBUMP_FLOATはオプションのバンプサイズの浮動小数点数値である。また、完全な法線構文を使っても良い。例えば: normal { hexagon normal { gradient x scale.2 }, normal { gradient y scale.2 }, normal { bumps scale.2 } } テクスチャで使う場合の構文は... texture { hexagon texture { T_Gold_3A }, texture { T_Wood_3A }, texture { Stone12 } } これはブロックパターンなので、ウェーブタイプ、カラーマップあるいは傾斜マップ修飾子は使えない。 7.6.7.12 Leopard(豹、レパード) (図 Leopardパターン) Leopard 円形の斑点の規則的な幾何学パターンを作成する。 このパターンはramp_waveウェーブタイプをデフォルトで使用するが、任意のウェーブタイプが使える。このパターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapで使っても良い。 7.6.7.13 Mandel(マンデル) (訳注:Mandelのサンプルはpov3demo\surfaces\mandel.povを参照) mandelパターンは標準のマンデルブロー・フラクタルパターンを計算し、それをx-y平面上に投影する。マンデルブロー集合の計算のためにxおよびy座標を用いる。このパターンは整数値が続くmandelキーワードで指定される。その数値は集合を計算するために使用される反復の最大数である。代表的な値の範囲は10から256であるが、任意の正の整数が使える。例えば: pigment { mandel 25 color_map { [0.0 color Cyan] [0.3 color Yellow] [0.6 color Magenta] [1.0 color Cyan] } scale.5 } このカラーマップに渡される値は以下の公式で計算される: value = number_of_iterations / max_iterations 法線パターンとして使われる場合の構文は... normal { mandel ITER, BUMP_AMOUNT } ここで必要な整数 ITER 値にはオプションで浮動小数点数値のバンプサイズが続く。 このパターンは平らな(planar)イメージマップと同様にz-方向に無限に広がる。このパターンはramp_waveウェーブタイプをデフォルトで使うが、任意のウェーブタイプを使うことができる。このパターンはcolor_map、pigment_map、normal_map、slope_map および texture_mapで使うことができる。 7.6.7.14 Marble(大理石、マーブル) (図 Marbleパターン) marbleパターンはgradient xパターンと非常に似ている。gradientパターンはデフォルトのramp_waveウェーブタイプを使う。このことは0.0から位置x=1で1.0までのカラーマップからのカラーを使い、それからx > 1では最初のカラーにジャンプして戻り、何度もそのパターンを繰り返すことを意味する。しかし、marbleパターンはtriangle_waveウェーブタイプを使う。そのタイプでは0から1までのカラーマップを使うが、それから1から0までマップを逆に混合し戻る。例えば: pigment { gradient x color_map { [0.0 color Yellow] [1.0 color Cyan] } } これは黄色(yellow)からシアン(cyan)まで混合し、それから突然また黄色に変わり、繰り返す。しかし、gradient x をmarbleで置き換えると、x座標が0.0から0.5に進むにつれ滑らかに黄色からシアンに混合され、それからなめらかにシアンからx=1での黄色に戻る。 初期のバージョンのPOV-Rayはウェーブタイプの変更を許さなかった。現在そのウェーブタイプはほとんどすべてのパターンに対して変更可能であり、marbleとgradient xの相違は、ただデフォルトのウェーブタイプの問題だけである。 動乱(turbulence)および適当なカラーマップとともに用いられた場合は、このパターンは現実の大理石、ひすいあるいは他のタイプの石の色の鉱脈(veins)のように見える。デフォルトではturbulenceを持たない。 このパターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapとともに用いて良い。. 7.6.7.15 Onion(タマネギ、オニオン) (図 Onionパターン) Onionはタマネギの層のような同心の球のパターンである。それぞれの層は1単位の厚さである。 このパターンはramp_waveウェーブタイプをデフォルトで使うが、任意のウェーブタイプを使っても良い。このパターンはcolor_map、pigment_map、normal_map、slope_map および texture_mapとともに用いて良い。 7.6.7.16 Quilted(キルト) (図 Quiktedパターン) quiltedパターンはもともとは法線パターンとしてだけ使うために設計された。quiltedパターンはそれがキルト(キルティングされた布)あるいはタイル貼りされた表面か何かのようなパターンを生成することからそう名付けられた。その正方形は実際に3-Dの１単位サイズの立方体である。 法線パターンとして用いた場合、これは特別な法線の動揺(perturbation)関数を用いる。このことはquiltedパターンは、法線(normal)構文の中で、法線マップ、傾斜マップあるいはウェーブタイプ修飾子とともには使えないことを意味する。 ピグメントパターンあるいはテクスチャパターンとして用いた場合、quiltedパターンは法線のquiltedと同様であるが、ピグメントと比較した場合、ほとんどの法線とは同一でない。ピグメントあるいはテクスチャ構文内で用いられた場合、quiltedパターンはデフォルトでramp_waveウェーブタイプを使うが、任意のウェーブタイプが使える。このパターンはcolor_map、pigment_mapおよびtexture_mapで使うことができる。 キルト間の縫い目あるいは目地(gouge)の曲率を調整するために2つのパラメータcontrol0 および control1が使われる。構文は: normal { quilted AMOUNT control0 C0 control1 C1 } これらの値は、一般に0.0〜1.0の範囲のあたりに守られるべきである。何も指定されなければデフォルトの値は1.0である。タイル間のこの目地は断面が傾斜した線と考えて下さい。 図 Quilted パターン。c0=0 でさまざまな値のc1。 図 Quilted パターン。c0=0.33でさまざまな値のc1。 図 Quilted パターン。c0=0.67でさまざまな値のc1。 図 Quilted パターン。c0=1 でさまざまな値のc1。 (図 Qiltedパターンの制御) このまっすぐな傾斜は、2つの制御値を調節することによってカーブするように作成することができる。制御値は、上部と底部でのカーブの傾斜を調節する。両端で0の制御値は上に示したように直線の傾斜を与え硬い感じの縁をみせる。両端で1の制御値は"s"型の曲線を与え、より柔らかな丸い縁の結果を生む。 7.6.7.17 Radial(放射、ラジアル) (図 Radialパターン) radialパターンは+y軸の回りに巻き付く放射状の混合である。値0.0のカラーは+x方向でスタートし、0.25の-z方向、-xの0.5、+zで0.75に東から西へカラーマップを巻き付け、+xの1.0に戻る。典型的にはこのパターンはy-軸から発する複数の帯を作成するためにfrequency修飾子とともに使われる。 このパターンはデフォルトでramp_waveウェーブタイプを使うが、任意のウェーブタイプが使える。このパターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapで使っても良い。 7.6.7.18 Ripples(波紋、リップル) (図 Ripplesパターン) ripplesパターンはもともとは法線パターンで使用するためだけに設計された。これは水の波紋のように見える表面を作成する。波紋は<0,0,0> から <1,1,1>の単位立方体領域内の10のランダムな位置から放出する。中心をより近くにあるいはより離れて作成するためにはパターンを拡大縮小して下さい。 通常、任意の与えられた中心からの波紋は1単位離れている。frequencyキーワードは波紋間の間隔を変更する。phaseキーワードはリアリスティックなアニメーションのために波紋の外側を移動するために使われる。 波紋の中心の数は、シーン内のどこかのグローバルパラメータglobal_settings {number_of_waves 浮動小数点数 }で変更することができる。これは全体のシーンに影響する。個々のパターンの波紋の中心の数を変更することはできない。詳しくは"Number_Of_Waves" を見て下さい。 法線パターンとして使われた場合、ripplesは専用の法線動揺(perturbation)関数を使う。これはripplesパターンは法線構文の中で法線マップ、傾斜マップあるいはウェーブタイプ修飾子と一緒には使えないことを意味する。 ピグメントあるいはテクスチャ構文で使われる場合、ripplesパターンはramp_waveウェーブタイプをデフォルトで使うが、任意のウェーブタイプを使える。パターンはcolor_map、 pigment_mapおよびtexture_mapで使える。 7.6.7.19 Spiral1(螺旋1、スパイラル1) (図 Spiral1パターン) spiral1パターンは、ネジと同様にy-軸に巻きつく螺旋を作成する。構文は: pigment { spiral1 NUMBER_OF_ARMS } NUMBER_OF_ARMSの値はいくつの腕がy-軸に巻き付くかを定める。 このパターンはデフォルトでtriangle_waveウェーブタイプを用いるが、任意のウェーブタイプが使える。このパターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapで使える。 7.6.7.20 Spiral2(螺旋2、スパイラル2) (図 Spiral2パターン) spiral2パターンは、奇妙な外観をもつspiral1パターンの修正である。 このパターンはデフォルトでtriangle_waveウェーブタイプを用いるが、任意のウェーブタイプが使える。このパターンはcolor_map、pigment_map、normal_map、slope_mapおよびtexture_mapで使える。 7.6.7.21 Spotted(斑点、しみ) (図 Spottedパターン) spottedパターンはbozoパターンと同じである。初期のバージョンのPOV-Rayではspottedにturbulenceを使うことができなかった。現在は任意のパターンでturbulenceが使えるのでbozoとspottedの間の違いはない。詳細は"Bozo"を見て欲しい。 7.6.7.22 Waves(波、ウェーブ) (図 Wavesパターン) wavesパターンはもともとは法線パターンだけで使うために設計された。 wavesパターンはその容貌がより丸く、幅広いことを除いてripplesと同じように見える。この効果はwavesをより深い海の波のように見せる。波は単位立方体<0,0,0> から <1,1,1>内の10のランダムな位置から放射される。中心をより近づけたり離したりするにはパターンを拡大縮小して下さい。 通常、与えられた中心からの波は、だいたい1単位離れている。frequencyキーワードは波の間の間隔を変更する。phaseキーワードは、リアリスティックなアニメーションのために波の外部を動かすために用いることができる。 波紋の中心の数は、シーンの中のどこかのグローバルパラメータglobal_settings {number_of_waves 浮動小数点数 } で変更できる。これはシーン全体に影響する。個々のパターンの波の中心の数は変更できない。詳細は"Number_Of_Waves"を見て下さい。 法線パターンとして用いた場合は、wavesは専用の法線動揺パターン関数を使う。このことはwavesパターンは法線マップ、傾斜マップ、法線構文中のウェーブタイプ修飾子と一緒には使えないことを意味する。 ピグメントあるいはテクスチャ構文で使われる場合は、wavesパターンはramp_waveウェーブタイプをデフォルトで使うが、任意のウェーブタイプが使える。このパターンはcolor_map, pigment_map および texture_mapで使うことができる。 7.6.7.23 Wood(木材、ウッド) (図 Woodパターン) woodパターンは、z-軸上に中心を置いた同心円筒から成る。適切に色をつけられてと、バンドは現実の木材の年輪と木目のように見える。少しの量のturbulenceを加えるとよりリアルな外観を作成できる。デフォルトではwoodはturbulenceを持たない。 ほとんどのパターンと違って、woodパターンは、デフォルトでtriangle_waveウェーブタイプを用いる。このことはmarbleのように、woodはカラーマップ値0.0から1.0を使い、それから1.0から0.0まで逆順にカラーを繰り返すということを意味する。しかし任意のウェーブタイプが使える。このパターンはcolor_map、pigment_map、normal_map、slope_map およびtexture_mapで使っても良い。 7.6.7.24 Wrinkles(しわ、リンクル) (図 Wrinklesパターン) wrinklesパターンはもともとは法線パターンとしてだけ使用するために設計された。これはgraniteと同様な1/fノイズパターンを使うが、wrinklesの容貌の方がよりシャープである。また、素敵な化粧漆喰(stucco)テクスチャを作成する。 法線パターンとして用いた場合は、専用の法線動揺関数を使う。このことはwrinklesパターンは法線マップ、傾斜マップ、法線構文中のウェーブタイプ修飾子と一緒には使えないことを意味する。 ピグメントあるいはテクスチャパターンとして用いた場合、wrinklesパターンは法線wrinklesと同様であるが、ピグメントと比較した場合、ほとんどの法線がそうであるようには同一でない。ピグメントあるいはテクスチャ構文で用いた場合wrinklesパターンはramp_waveウェーブタイプをデフォルトで使うが、任意のウェーブタイプが使える。このパターンはcolor_map、pigment_mapおよびtexture_mapで使える。 7.6.8 パターン修飾子(Pattern Modifiers) パターン修飾子は構文あるいはパラメータであり、パターンがどのように評価されるか修正し、パターンで何をするかを告げる。修飾子color_mapおよびpigment_mapはピグメントだけに適用される。セクション「ピグメント」参照。修飾子bump_size、slope_mapおよびnormal_mapは法線だけに適用される。セクション"Normal"参照。texture_map修飾子はテクスチャだけで使うことができる。セクション「テクスチャマップ」参照。 以下のセクションのパターン修飾子はピグメント、法線あるいはテクスチャパターンで使える。 7.6.8.1 パターンの変換(Transforming Patterns) 最も一般的なパターン修飾子は変換修飾子translate、rotate、scaleおよびmatrixである。これらのコマンドの詳細は「変換」を見て下さい。 これらの修飾子はパターンの位置、サイズおよび向きを変更するためにピグメント、法線およびテクスチャ構文の内側に置くことができる。 一般に動乱(turbulence)、カラーマップ(color_map)および他のマップのような他のパターン修飾子に相対的な変換の順序は重要ではない。例えば、turbulenceの前あるいは後の拡大縮小は何の違いにもならない。turbulenceは最初に指定されたかどうかには関係なく最初になされ、それから拡大縮小がなくなされる。しかしながらwarp構文に相対的に行われる変換の順序は重要である。詳細は"Warps"を見て欲しい。 7.6.8.2 周波数と位相(Frequency and Phase) frequency(周波数) および phase(位相)修飾子はカラーマップ(color_map)、ピグメントマップ(pigment_map)、法線マップ(normal_map)、傾斜マップ(slope_map)およびテクスチャマップ(texture_maps)に対するscaleおよびtranslate修飾子のタイプのように動作する。本義論では例としてカラーマップを使うが、ピグメントマップ、法線マップ、傾斜マップおよびテクスチャにも同じ原理が適用できる。 frequencyキーワードはカラーマップが1循環のパターンを繰り返す回数を調整する。例えば、gradientは x=0 から x=1までの範囲でカラーマップ値0から1までをカバーする。 frequency 2.0 を加えると、カラーマップは同じ範囲に対して2回繰り返される。同じ効果を成し遂げるためにscale 0.5*xを使うことができるので、frequencyキーワードはgradientのようなパターンには役に立つとはいえない。 しかしながら、radialパターンはカラーマップを+y-軸のまわりに一度巻き付ける。もしマップの2つのコピーが(あるいは 3 あるいは 10 あるいは 100)欲しい場合、より大きなマップを作らなければならない。frequency 2.0 を追加すると一回転あたり2回のカラーマップが使われるようにすることができる。以下を試そう: pigment { radial color_map{[0.5 color Red][0.5 color White]} frequency 6 } この結果はオブジェクトのまわりに6つの組の等間隔の赤と白の放射状ストライプになる。 frequencyの後ろの浮動小数点数値は任意の値でよい。1.0より大きな値では1つより多くのマップのコピーが使われる。0.0 から1.0までの値はマップの一部分が使われる。負の値はマップを逆にする。 phase値はマップのエントリをシフトし、マップの開始と終了が異なる位置になるようにする。上の例であなたがphase 0 その後 phase 0.1、phase 0.2 などで連続したフレームをレンダリングすると、ストライプが回転するアニメーションを得るだろう。同じ効果はradialピグメントをrotate y*Angleを用いて回転させても簡単に成し遂げることができるが、phaseの方が扱いやすい他の用途がある。 時として、あなたは素晴らしい見かけのgradientあるいはwood カラーマップを作成して、木目をわずかに調整したいかもしれない。あなたはカラーマップのエントリを再配置することができるがそれは苦労を伴う。phase調整はすべてをシフトするが縮尺を同じに保つ。カラーパレットの回転効果を見るためにmandelピグメントをアニメーションにしてみて下さい。 Frequencyおよびphaseはchecker(チェッカー)、brick(煉瓦)およびhexagon(六角形)ブロックパターンに対しては何の効果も持たないし、それらはイメージマップ、バンプマップあるいはマテリアルマップを生じない。それらはまた、bumps(でこぼこ)、dents(くぼみ)、quilted(キルト)あるいはwrinkles(しわ)が使われた法線構文で効果を持たない。なぜならばそれらの法線パターンはnormal_mapあるいはslope_mapを使えないからである。 これらは、二つのパターンはnormal_mapとslope_mapのいずれもが使えないけれども、法線パターンripples(波紋)とwaves(波)とともに使える。ripplesあるいはwavesとともに用いた場合、frequencyはフィーチャー間の間隔を調整し、phaseはこのフィーチャーをアニメートするためにその中心に対して相対的に波あるいは波紋が動くように、0.0から1.0に調整することができる。 これらの値は以下の公式に適用されることにより動作する NEW_VALUE = fmod ( OLD_VALUE * FREQUENCY + PHASE, 1.0 ). 7.6.8.3 波形(Waveform) color_map、pigment_map、slope_map、normal_map あるいはtexture_mapをとるほとんどのパターンは0.0 から1.0の順序でマップ内にエントリを使う。wood(木)およびmarble(大理石)パターンは0.0から1.0までのマップを使い、それからそれを逆にし、1.0 から 0.0まで実行する。それらの違いは、それらのパターンをマップのない法線パターンとして使うと簡単に分かる。 gradient(勾配) あるいは onion(たまねぎ)のようなパターンは鋭く下がる傾斜路の様に見える木立か溝を生成する。これは ramp_wave(傾斜波)ウェーブタイプと呼ばれる。しかし、woodとmarbleは頂上まで上に傾斜しそれから再び下り坂になりtriangle_wave(三角波)になる。以前のバージョンのPOV-Rayではウェーブタイプを変更する方法がなかった。マップエントリを逆に繰り返すことによりrampウェーブパターンでtriangleウェーブをシミュレートすることができたが、rampウェーブをwoodあるいかmarbleで使う手だてがなかった。 現在、任意のマップを持つパターンが無効にされたデフォルトのウェーブタイプをもてる。例えば: pigment { wood color_map { MyMap } ramp_wave } またsine_wave(正弦波)およびscallop_wave(スカラップ波、扇形切り欠き波)タイプが利用できる。これらのタイプは組み込み傾斜マップとして主として法線パターンで使われる。sine_waveはrampウェーブのジグザグをとってそれをスムーズな変化によりゆるやかにうねる波に変える。scallop_waveは正弦波の絶対値を使い、小さく縮小された場合コールテンの様に見え、大きく拡大された場合、たくさんの円筒のようである。 それらのウェーブタイプの多くはピグメント、法線あるいはテクスチャで使うことができるが、 sine_waveとscallop_waveタイプは法線として使われら場合ほどピグメントやテクスチャでは目立たない。 ウェーブタイプはブロックパターンchecker、brickおよびhexagonに効果を持たないし、それらはイメージマップ、バンプマップあるいはマテリアルマップに効果を生じない。またそれらは法線構文でbumps、dents、quiltedあるいはwrinklesとともに使われても効果を生じない。なぜならそれらの法線パターンはnormal_mapあるいはslope_mapを使えないからである。 7.6.8.4 動乱(Turbulence:乱れ・乱気流) Turbulence(動乱※)には浮動小数点数あるいはベクトルが続き、任意のピグメント、法線、テクスチャ、irisあるいはハローをかき回すために使われる。多くのオプションのパラメータがどのように計算するか制御するためにturbulenceで使われる。例えば: (※訳注:動乱と訳す) pigment { wood color_map { MyMap } turbulence TURB_VECTOR octaves 浮動小数点数 omega 浮動小数点数 lambda 浮動小数点数 } 代表的なturbulence値の範囲はデフォルトの0.0の動乱なし、から1.0あるいはそれ以上の非常に乱れている(荒れ狂う)である。ベクトルが指定された場合、x-、y-、z-方向で異なる量の動乱が適用される。例えば turbulence <1.0, 0.6, 0.1> はx-方向により多くの乱れを持ち、y-方向に中位の、z-方向に少しの乱れを持つ。 TurbulenceはDNoiseと呼ばれるランダムノイズ関数を使う。これは一つの値を与える代わりに方向(direction)を与えることを除きbozoパターンで用いられているノイズと同じである。それはその場所で吹いている風の方向と考えることができる。互いに接近している点はほとんど同じ値であるが遠く離れている点はランダムに異なる。 一般に変換、カラーマップあるいは他のマップとの相対的なturbulenceパラメータの順序は重要ではない。例えばturbulenceの前後の拡大縮小は何の違いも生じない。どちらが最初かによらずturbulenceが最初になされ拡大縮小が行われる。"Warps"をこの挙動のまわりでの動作方法について見て下さい。 Turbulenceは点のまわりをオクターブ(octave)と呼ばれる何回かのステップで押すためにDNoiseを使う。評価したい点を見つけて、異なる点を得るためにturbulenceを用いてまわりに少し押す。それから新しい点のカラーあるいはパターンを参照する。 要するに、この地点のカラーはいらないから...いろいろな方向へ2、3回ランダムステップしてからそのカラーを下さいということである。各ステップは典型的には前の値の半分の長さである。例えば: P -------------------------> 最初の移動 / / / /2回目の / 移動 / ______/ \ \ Q - 最終点。 図()　動乱(Turbulence)のランダムウォーク。 これらのステップの大きさは、turbulence値によって制御される。turbulenceがどのように計算されるか制御する3つの付加パラメータがある。それらは、オクターブ、ラムダおよびオメガである。各々は、オプショナルである。各々には一つの浮動小数点数値が続く。turbulenceがないとき、各々は効果を有しない。 7.6.8.5 Octaves(オクターブ) オクターブ(octaves)値は計算される動乱(turbulence)のステップの数を制御する。正当な値の範囲は1から10である。デフォルト値の6はかなり高い値である;たくさんに見えない場合は、余分なステップがあまりに小さいためであるから、より高い値をセットすることにより変更して下さい。浮動小数点数値は整数に切り捨てられる。小さな値のオクターブは穏やかな波形の動乱を与え、計算はより速くなる。高いオクターブはよりたくさんのギザギザあるいははっきりしない(fuzzy:ファジー)動乱を作成し、より計算は長くかかる。 7.6.8.6 Lambda(ラムダ) ラムダ(lambda)パラメーターはオクターブのランダムな動きがそれ以前のオクターブと比較して統計学的にどのくらい異なるかを制御する。デフォルト値は2.0であり、とてもランダムである。lambda 1.0に接近した値は上の図の中の経路のランダムさを整ったものにする。その計算におけるジグザグなステップはほとんど同じ方向である。より高い値は、いくつかの状況の下でより渦状(swirly)に見える。 7.6.8.7 Omega(オメガ) オメガ(omega)値は、それぞれの連続したオクターブステップが前の値に比べてどれくらい大きいかを制御する。動乱(turbulence)のそれぞれの連続したオクターブはオメガ値を掛けられる。デフォルトのオメガ(omega) 0.5 はそれぞれのオクターブは直前のものの1/2のサイズであることを意味する。高いオメガ値は2番目、3番目,４番目およびその上のオクターブが、より鋭い、しわくちゃに見えるより多くの動乱に寄与することを意味し、より小さいオメガはその場所をぼかすファジーな種類の動乱を与える。 7.6.8.8 ワープ(Warps:ゆがみ) ワープ(warp)構文はturbulenceに類似したパターン修飾子である。 Turbulenceはパターンの評価点を取り、それを一連のランダムなステップにより押すことにより機能する。しかし、ワープはとてもうまく定義された、ランダムでない、幾何学的方法で点を押す。ワープ構文もまた、パターンに適用されたturbulenceと変換およびワープ修飾子の適用順序のコントロールをユーザーに与え、いくつかの伝統的なturbulenceと変換およびワープ修飾子の制限を克服する。 現時点では3種のワープがあるが、構文は将来の拡張を許すものである。最初の2つのrepeat warp(繰り返しワープ)とblack_hole warp(ブラックホールワープ)はPOV-Rayの新しい機能であり、幾何学的方法でパターンを修正する。他のワープはturbulence指定の別の方法である。 ピグメント内でのワープ構文を使用する構文は pigment { パターンタイプ ピグメント修飾語... warp { WARP_ITEMS..}. 他のピグメント修飾語... } 同様の方法でワープを法線およびテクスチャ内で使っても良い。それぞれのパターンに要望に合わせてたくさんの個々のワープ構文を持っても良い。カラーマップや turbulenceのような他の修飾子との相対的位置に問題はない。しかしながらワープ構文相互と変換との相対的な位置には意味がある。複数のワープと変換はあなたの指定した順序で評価される。例えば変換してワープするのとワープしてから変換するのでは異なる結果となる。 7.6.8.8.1 ブラックホールワープ(Black Hole Warp) ブラックホールという名前は、実際のブラックホールとの類似性から名付けられた。実物のように、このブラックホールを実際に見ることはできない。その存在を検出する唯一の方法は、それがまわりの物体に対して持つ効果である。しかしながら、実際のものとは違って、あなたが近くに寄りすぎても(我々はその部分で働いている)、それはあなたを飲み込まないし、あなたのからだ全体を直径2.0*10^-10ミクロンの体積に圧縮しはしない。 woodgrain(木目)を例として使おう。POV-Rayの法線動乱(turbulence)と他のテクスチャ修飾関数を用いて、あなたは木目に素晴らしいランダムな外観を得ることができる。しかし、そのランダム性においてそれは規則的である−それは、規則正しくランダムである！woodgrainに一つあるいは複数の場所にブラックホールを付け加えることにより、局所化された動揺を作成するこができる。ブラックホールは回りのテクスチャを(実際のもののように)それ自身に吸い込むか、あるいはそれを押し離す効果を持つことができる。後者の場合、woodgrainに適用されると、観察者には節穴が木材にあるように見える。本テキストでは一様にwoodgrainを例として用いる。それがブラックホールを説明するのに理想的にふさわしいからである。しかしながら、ブラックホールは実際には任意のテクスチャに使える。 (訳注:ブラックホールの木目への応用についてはpov3demo\surfaces\blkhole.povが参考になるだろう。) ブラックホールがテクスチャ上に有する効果を指定することができる。デフォルトで、指数関数的(二乗の逆数:inverse-square)に計算された強度で吸収する。好みによってこれを変更することができる。 ブラックホールはワープが許される場所ならどこででも使える。構文は: warp { black_hole <中心>, 半径 [falloff 値] [strength 値] [repeat <ベクトル>] [turbulence <ベクトル>] [inverse] } いくつかの例を与えよう warp { black_hole <0, 0, 0>, 0.5 } warp { black_hole <0.15, 0.125, 0>, 0.5 falloff 7 strength 1.0 repeat <1.25, 1.25, 0> turbulence <0.25, 0.25, 0> inverse } warp { black_hole <0, 0, 0>, 1.0 falloff 2 strength 2 inverse } ブラックホールがどのように働くかを完全に理解するためには、その背後にある理論を知っていることが重要である。ブラックホール（あるいは、ワープ）は、点をとって、別の場所にそれを動揺させることによって働く。動揺(perturbation)の量は、それに通過されたオリジナルの点でのブラックホールの強度に依存する。動揺の量はあなたが見るテクスチャに起こる視覚的な移動の量に直接関係する。入力座標でのブラックホールが強いほどオリジナルな座標は他の位置により多く移動する(ブラックホールの中心から離れているか、近くにあるかどちらか。) 常に、動きは入力点とブラックホールの中心の間に存在するベクトル上で起こる。 ブラックホールは球であるとみなされる。点がブラックホールによって影響を受けるためには、それが球の体積の範囲内でなければならない。 あなたが <1,1,1>にあるブラックホールと<1,2,1>の点を持つとしよう。もしこの点が総量+1で動揺されると、その新しい位置は<1,3,1>となり、ベクトル<1,1,1>と<1,2,1>から推定される真っ直ぐな線上にある。この場合、その点はブラックホールから押し離され、それは普通の動作ではないがデモンストレーションの目的には良い。 ブラックホールの内部特性は、次のようである。 Center ブラックホールの中心。 Radius その半径。 Falloff 2のべき乗で減退効果を与える(デフォルトは2。) Strength 変換効果の大きさ(以下を見よ。) Inverted セットされると点を"引き"寄せる代わりに'押し'離す。 Repeat セットされると、1つではなく複数のブラックホールを得る。 Turbulence セットされると、新しい繰り返しブラックホールの位置が不確定になる。 Repeat_Vector 繰り返す 係数。 Turbulence_Vector turbulenceのランダムさの最大の係数。 これらのそれぞれを以下で議論する。 Center : ブラックホールを表す球の中心を定義しているベクトル。ブラックホールが繰り返しセットを有する場合、それは各々のブロック範囲内のオフセットである。 Radius : ブラックホールを表す球の半径の長さを単位で与えている数。 点が
の半径単位の範囲内にないならば、それはブラックホールによって影響を受けることがなく、かき乱されないだろう。 Falloff : ブラックホールのパワーが減退する指数。デフォルトは2。Strength修飾子が適用される前の、任意の与えられた点におけるブラックホールの力は以下のようである。 最初に、その点からブラックホールの中心までの距離を、ブラックホールの縁からその点まででの(0から1)の割合に変換する。ブラックホールの周辺部の上の点は0.0であろう；中心における点は1.0であろう；正確に中間点では0.5、などであろう。 精神的に、あなたはこれが近さ係数(closeness factor)であるとみなすことができる。1.0の近さはできるだけ中心に接近した場合(つまり中心)、0.0の近さは、できるだけ中心から遠く離れてまだブラックホールの内部にいる場合で、近さ0.5は2つの間の正確な中間点を意味する。 この値をcと呼ぼう。Falloffで指定された指数がcのべき乗される。デフォルトでFalloffは2であり、これはc^2あるいはcの平方である。結果として生ずる値はその正確な位置でのブラックホールの強度であり、強度スケーリング係数(Strength scaling factor)を適用された後、空間上でその点がどのくらい多く動揺させられるかを決めるために使われる。 例えば、もしc が 0.5なら、力(force)は0.5^2,あるいは0.25である。もし、cが0.25なら、力は0.125である。しかし、もしcが正確に1.0ならば力は1.0である。 cがより小さい値を得るということはその点がブラックホールの中心からより遠いということを思い出そう。デフォルトの指数2を用いると、cが小さくなると力は指数関数的に平方の逆数(inverse-square)の関係で小さくなる。平易な英語置き換えると、力(force)が外側よりも中心に向かって、より強くなる(2のべき乗で) 。 Falloffを増加させると、減退の力を増加させることができる。大きい値は周辺部の方の点が全くほとんど影響を受けないだろうことを意味するだろう、そして、中心の方の点は強く影響を受けるだろう。 Falloffの値1.0はその効果が線形であることを意味する。正確にブラックホールの中心からの中間地点の点は正確な力0.5で影響される。 Falloffの値が1より小さく0より大きい場合は、あなたが外側に近づくにつれ力が減るのではなく、そのかわりに増加することを意味する。このことはいくつかの用途を有するが、しかし副作用がある。ブラックホールの効果が、その周辺部の外側で終わることを思い出そう。このことは許容値ERの範囲内の点のみが強く影響され、その外側のものは全く影響されないことを意味する。これは、球として形づくられる見える境界に導く。 Falloffの0の値は0のべき乗は0より大きいどんな値でも1.0であるからブラックホールの内側のすべての点で力が1.0であることを意味する。 点の動きの大きさは、基本的に力の値によってスケーリングした後に決められる。我々は、後にスケーリングを考慮するだろう。例を用いよう。 半径2.0のブラックホールとその中心から正確に1.0離れた点を考えよう。それは中心から正確に中間の位置で、cが0.5であることを意味する。デフォルトの減退(fall off)2を使うとするとその点の力は0.5^2あるいは0.25である。これが何を意味するかというと、その点をその中心からの距離の0.25倍動かさなければならないことである。この場合それは中心から1.0単位であるから、それを1.0*0.25あるいは0.25単位動かす。これは元の位置と中心の間の3次元空間内の直線上で、中心からの最終的な距離1.0-(1.0*0.25)あるいは0.75単位を与える。 もしその点が、例えば木目の、一部であったとすると、その木目は(見えない)ブラックホールの中心の方へ向かって曲がるように見える。もしInverseフラグがセットされたらそれは押し離され、最終位置は中心から1.0+(1.0*0.25)あるいは1.25単位になることを意味する。 Strength :Strengthはブラックホールによって点がどれくらい多く動揺させられるかをもう少し制御することを可能にする。基本的にブラックホールの(上で決めた)強度はStrengthの値が掛けられる。これはデフォルトで1.0である。もし、例としてStrengthを0.5にせっとすると、ブラックホール内のすべての点は、以前の量に比べてただ半分の量だけ移動するもしそれを2.0にセットすると、2倍の量移動する。 けれども後者の例には添え書きがある、その動きは中心からの元の距離の最大値でクリップされる。これはいわば中心から0.75単位の点はStrengthの値には関係なく最大で0.75単位中心に向かってあるいはそれから離れて動くことができるということである。このクリッピングの結果、ブラックホールの中心近くに、力の最終値が1.0以上になったすべての点が固定量で移動された除外領域を有するだろう。 Inverted : Invertedがセットされた場合、点は引き込まれる代わりに中心から押し離される。 Repeat : Repeatは明示的にそれを宣言せずにたくさんのブラックホールの効果をシミュレートすることを可能にする。Repeatはベクトルであり、POV-Rayにこのブラックホールを複数の位置で使うように指示する。 もしあなたがこれらすべての背後の理論に興味がなければ以下のテキストをスキップして、下記の要約の中で与えられた値を使いなさい。 Repeatの使用は論理的にあなたのシーンを立方体に分割する。最初は <0,0,0>に位置し、まで進む。repeatベクトルが<1,5,2>としよう。最初の立方体は<0,0,0>から<1,5,2>までになる。この立方体が繰り返され、<-1,-5,-2>、<1,5,2>、<2,10,4>およびすべての方向に無限のものになる。 Repeatを用いた場合、シーンの中でのブラックホールの中心の絶対値を指定することはできないが各ブロックに対するオフセットを指定できる。正のオフセットだけが使える。負数は未定義の結果を生ずる。 中心が<0.5,1,0.25>でrepeatベクトルが<2,2,2>としよう。これは<0,0,0>および<2,2,2>、などのブロックを与える。これらのブロックのブラックホールの中心は<0,0,0> + <0.5,1.0,0.25>、つまり<0.5,1.0,0.25>、および<2,2,2> + <0.5,1.0,0.25>、つまり<2,5,3.0,2.25>となる。 内部で計算される繰り返しの方法のために、繰り返しベクトルにあなたが指定する値の上限がある。基本的に、各ブラックホールは隣り合うものと交差することなく各ブロック(あるいは立方体)ですっかり囲まれていなくればならない。これはx、y、zのそれぞれの次元に対して中心のオフセットが半径より小さくてはならず、他の値だとブラックホールが境界に交差するので、その次元に対するrepeat値>=中心+半径でなければならないことを意味する。言い換えると、各x、yおよびzに対して 半径 <= オフセット あるいは 中心 <= repeat - 半径。 もし各次元のrepeatベクトルがこの基準に合うにはあまりに小さいならば、それは増加させられ、警告メッセージが出るだろう。中心が半径より小さいならば、それは動かされるが、メッセージは出ないだろう。 注意：上記のいずれもがブラックホールのオーバーラップができないことを意味すると読まれるべきではない。確かにできるし、実際、それはいくつかの最も多く役に立つ効果を生じることができる。制限は、繰り返している同じブラックホールの要素に適用されるだけである。あなたは第2のブラックホールを宣言することができる。それはまた繰り返し、その要素がとても運良く最初のものにオーバーラップし適当な相互作用を引き起こす。 value値の任意の次元を0にすることは正当であり、POV-Rayがそのブラックホールをその方向に繰り返さないことを意味する。 Turbulence : TurbulenceはRepeatと一緒にだけ使用できる。ブラックホールがより自然の外観を引き起こすように、偶然性の要素を繰り返し方法に挿入することを許す。良い例は木材のずらりと並んだ節穴であろう−もし各節穴が前ののと正確な間隔であるとむしろ人工的に見える。 turbulenceベクトルは、ベクトルの各軸が0から1の範囲の異なるランダム量で掛けられた後で、配列内の個々のブラックホールに加えられる測定値である。 例えば、<2,2,2>にあると仮定されるブラックホールの繰り返し要素があると仮定しなさい。あなたは、<4,5,3>の動乱ベクトルを指定した。これはあなたがx方向に1.0単位、y方向に3.0単位およびz方向に2.0しか変化しないで欲しいことを意味する※。(※訳注:xが2でzが1では)このことは新しい位置の有効な範囲は以下の通りであることを意味する X は2から6まで。 Y は2から7まで。 Z は2から5まで。 この特定の繰り返し要素に対するブラックホールの結果の位置はランダムであり(しかし一貫的でありレンダリングは繰り返し可能である)上の座標内のどこかである。 turbulenceの使用における添え書きがある。それは基本的にrepeatベクトルのものと同じである。あなたは、ブラックホールがその特定のブロックの外側で交差する可能性を持つような値を指定することができない。 POV-Rayは変化のランダムな性質によりどのくらいの位置が変化するかを前もっては知らないので、 各軸に対する中心方向への可能な最大変動を加えることを除きRepeatに対するものと同じ規則を実施する。例えば、中心が<1.0, 1.0, 1.0>、半径0.5のブラックホールと普通の<0.5, 0.25, 0>のturbulenceがあると、最小の繰り返し(repeat)は<1.5, 1.5, 1.5>となる。しかし、今turbulenceを考慮すると、最小繰り返しベクトルは実際には<2.0, 1.75, 1.5>となる。 Repeat の要約:各 x、yおよびzに対して中心のオフセットは>= 半径でなければならず、repeatの値は>= 中心 + 半径 + turbulenceでなければならない。例外は任意の次元に対するrepeatが0であるときで、その方向には繰り返しがなされないことを意味する。 7.6.8.8.2 繰り返しワープ(Repeat Warp) 繰り返しワープ(repeat warp)によって、パターンの一部が次々と繰り返されるようになる。パターンからのスライス(薄切れ)をとって、その複数のコピーを並べて作成する。ワープは多くの用途を持つが、もともとはベニヤ板(wood veneer)テクスチャのモデル化を容易にするために設計された。ベニヤ板は、丸太からとても薄いスライスをとって、いくつかの他の背景になる材料の上にそれらを並べて置くことによって作成される。あなたはほとんど同一のリングパターンが並んでいるのを見るが、それぞれは多分1/32インチの深さとなるだろう。 繰り返しワープの構文は warp { repeat ベクトル offset ベクトル flip ベクトル } repeatベクトルはパターンが繰り返される方向と繰り返される領域の幅を指定する。このベクトルは完全に軸に沿って横たわらなければならない。言い換えると3つの成分の内2つが0でなければならない。例えば pigment { wood warp {repeat 2*x} } これは、x=0からx=2までは通常あるパターンは何でも得られることを意味する。しかし、x=2からx=4までは、x-軸方向に2単位正確にシフトされた同一のものを得る。それを評価するためには単にx-座標の2を法とする値をとればよい。残念なことに、あなたはあまり現実的でない正確な複製を得る。オプションのoffsetベクトルは、毎回の繰り返しでどのくらい多くパターンが平行移動されるかを指定する。例えば pigment { wood warp {repeat x*2 offset z*0.05} } は最初のコピーをx=0から x=2までz=0でスライスし、 x=2 から x=4ではz=0.05へオフセットする事を意味する。4から6までの区間でz=0.10でスライスする。n-番目のコピーでは0.05 n zでスライスする。このように各々のコピーは僅かに異なる。オフセット(offset)ベクトルにはなんの制限もない。 最後にflip(フリップ)ベクトルはパターンを一つ置きにフリップ(飛び移る）あるいは鏡映にすることを引き起こす。軸から正方向のパターンの最初のコピーはフリップしない。次に遠いのはして、その次はしない、その他。flipベクトルは3成分x、y、zベクトルであるが、各成分はブーリアン値として扱われ、与えられた軸に沿ってフリップすべきかそうでないかを指定する。例えば pigment { wood warp {repeat 2*x flip <1,1,0>} } パターンの一つ置きのコピーがx-およびy-軸に関して鏡映されるがz-軸に関してはされないことを意味する。ゼロでない値はその軸に関してフリップを意味し、ゼロはフリップしないことを意味する。flipベクトルの値の大きさは重要ではない。 7.6.8.8.3 動乱ワープ(Turbulence Warp) POV-Ray言語は動乱(turbulence)とtranslate、rotate、scaleおよびmatrix変換のような変換の指定において曖昧さと制限を持つ。通常turbulenceが最初になされる。その後すべてのtranslate、rotate、scaleおよびmatrix操作が常にそれらの指定順序によらずturbulenceの後になされる。例えば pigment { wood scale.5 turbulence.2 } は正確に pigment { wood turbulence.2 scale.5 } と同一である。 turbulenceは常に最初である。この制約のより良い例が不均一な動乱と回転である。 pigment { wood turbulence 0.5*y rotate z*60 } // 以下と比較 pigment { wood rotate z*60 turbulence 0.5*y } あなたが異なって見えるべきだと思っても、この結果は両方とも同じである。 現在のPOV-Rayのこの基本的な動作を変更することはできない。なぜなら過去において、もし突然に変換と動乱の順序が問題になると、たくさんのシーンがもしかすると違ってレンダリングされるだろうからそれはできなかった。 しかしながら、ワープ構文の内側にturbulenceを指定することにより、動乱、変換および他のワープが適用された順序が意味のあるものであることをPOV-Rayに告げる。ここに動乱ワープの例がある。 warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 } この意味するところは、 pigment { wood translate <1,2,3> rotate x*45 scale 2 warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 } } は以下のものと異なる結果を生み出す... pigment { wood warp { turbulence <0,1,1> octaves 3 lambda 1.5 omega 0.3 } translate <1,2,3> rotate x*45 scale 2 } ワープ構文を使うことなく動乱(turbulence)を指定しても良い。しかしながらそれをwarp内部に置くことなくそれらが評価される順序をコントロールすることができない。 評価の規則は以下のようである: 1) 最初に、ワープ構文の内側にないturbulenceはそれがワープあるいは変換と相対的現れる順序によらず適用される。 2) 次に、それぞれのワープ構文、translate、rotate、scaleあるいはmatrixの一つずつはユーザーが指定した順序に適用される。もし、turbulenceを指定した順序に実行したいのであれば、単に正しい位置のwarpの内側に指定すればよい。 7.6.8.9 ビットマップ修飾子(Bitmap Modifiers) ビットマップ修飾子(bitmap modifier)は、どのように2-Dビットマップを3-D表面に適用するかを指定するために"image_map"、"bump_map"あるいは"material_map"内部で用いられる修飾子である。いくつかのビットマップ修飾子は特定の種類のマップに適用され、それらは適当なセクションでカバーする。以下に続くセクションで議論するビットマップ修飾子は全3タイプのビットマップに適用可能である。 7.6.8.9.1 once(一度)オプション 通常、x-y-平面にタイルのようにすべてが単位正方形で作られた無限の数の繰り返されたイメージマップ、バンプマップあるいはマテリアルマップがある。ファイル名の後ろにonceキーワードを加えることによって、(0,0)から(1,1)までの一つを除き他のすべてのコピーを除くことができる。イメージマップでは、この単位正方形の外側は完全に透明として扱われる。バンプマップでは、この単位正方形の外側法線の変更がない平らなまま残る。マテリアルマップでは、この単位正方形の外側はテクスチャリストの最初のテクスチャでテクスチャ付けされる。 例えば: image_map { gif "mypic.gif" once } 7.6.8.9.2 map_type(マップタイプ)オプション バンプ(bump)のx-y平面への投影はデフォルトで平面マップ(planar map)と呼ばれるタイプになる。このオプションはオブジェクトのまわりにバンプを巻き付ける方法を指定する数値が続くmap_typeキーワードを加えることにより変更しても良い。 map_type 0 はデフォルトの既に述べた平面マッピングである map_type 1 は球状マッピング(spherical mapping)である。オブジェクトは原点に置かれた任意の大きさの球と仮定される。y-軸は球状マッピングの北/南極である。ビットマップぷの頂上と底のへりはスケーリングによらずちょうど極に接触する。ビットマップの左のへりは正のx-軸から始まり、球のまわりに-y-まわりで西から東にパターンを巻き付ける。パターンは球をちょうど一回だけ覆う。このタイプに対してはonceキーワードは意味をなさない。 map_type 2 では円筒状マッピング(cylindrical mapping)を得る。y-軸に沿って置かれた任意の直径の円筒を仮定する。バンプパターンは球状マッピングのように円筒のまわりを覆うが、y=0からy=1までの1ユニットの高さにとどまる。このパターンのバンドがonceキーワードが適用されない限り全高さまで繰り返される。 最後のmap_type 5はトーラスあるいはドーナッツ形マッピング(torus or donut shaped mapping)である。主半径1のトーラスがx-z平面内で原点に置かれているものと仮定する。パターンは球状あるいは円筒状マップと動揺にまわりを覆う。しかしマップの頂上と底のふちはトーラスの上と下を包み、内側のへりで互いに出会う。 タイプ3と4はまだ開発中である。 例えば: sphere{<0,0,0>,1 pigment{ image_map { gif "world.gif" map_type 1 } } } 7.6.8.9.3 補間(interpolate)オプション interpolateキーワードを加えることによりギザギザに見えるビットマップを滑らかにする。POV-Rayがイメージマップのカラーあるいはバンプマップのバンプ量を求める場合、 直接一つのピクセルの表面(top)でなく、異なるいくつかの色の付いたピクセルのある種の点を求める。補間は中間的な値を返すのでマップ内のピクセル間の段はより滑らかに見える。 けれども、補間はマテリアルマップに対しては正当であり、そのカラーインデックスはテクスチャが選択される前に補間される。あなたが望むかも知れないようには最終的なカラーは補間されない。一般に、マテリアルマップの補間は役に立つ目的にはかなわないが、これは将来のバージョンでは修正されるかも知れない。 現在2つのタイプの補間がある: 双線形(Bilinear) - interpolate 2 正規化距離(Normalized Distance) - interpolate 4 例えば: image_map { gif "mypic.gif" interpolate 2 } デフォルトは補間なしである。正規化距離は2つの中ではわずかながら速い方である。双線形はカラーの間をつまむにはより良い仕事をする。通常は双線形が使われる。 もしマップがギザギザに見えたら、高解像度のイメージにする前に補間を使ってみて下さい。結果は非常に良くなるだろう。 7.7 大気の効果(Atmospheric Effects) 大気の効果は、シーンを囲んでいる背景や大気に影響を及ぼす機能のゆるく編まれたグループである。POV-Rayは、霧、かすみ、霧、虹と空のようなたくさんの大気の効果をレンダリングする能力を持つ。 (訳注:大気に関するサンプルはpov3demo\atmosディレクトリにある。 atomos1.pov:スポットライトのある大気環境 atomos2.pov:スポットライトのある大気環境 atomos3.pov:スポットライトのある大気環境 atomos4.pov:スポットライトのある大気環境 atomos5.pov:スポットライトのある大気環境 foglayr.pov:透過を用いたフォグ foglay2.pov:透過を用いたフォグ fog_f.pov:フィルタを用いたフォグ fog_ft.pov:フィルタと透過を用いたフォグ fog_std.pov:フィルタと透過のないフォグ hollow1.pov:中空と中実オブジェクトの効果 hollow2.pov:ハローコンテナオブジェクト内の中空と中実オブジェクトの効果 hollow3.pov:炎で満たされた中空のチェックの球 nufog2.pov:霧の中にあるたくさんのボックスの距離感 rainbow1.pov:カラフルな虹 skysph1.pov:天球1 skysph2.pov:天球2 ) 7.7.1 大気(Atmosphere) 重要な注意:POV-Ray 3.0の大気の機能はいくぶん実験的なものである。これらの機能の設計とインプリメンテーション(実現)は将来のバージョンで変更される可能性が高い。我々は、3.0でこれらの機能を用いているシーンが、今後のリリースで同じくレンダリングできるか、あるいは言語構文の後ろ向き互換性を完全に維持することができるかどうかを約束することができない。 コンピュータで生成されるイメージは、通常、煙、光のビーム、その他のような自然現象のレンダリングを許さない真空空間を仮定する。シーンに霧を付け加えるとても単純な方法は、セクション「フォグ」の中で説明される。この種類の霧は、光源と影響し合わないけれども。それは光のビームや他の効果を示さないのでそれほどリアリスティックではない。 大気効果(atmosphere effect)は、体積サンプリング(volume sampling)を用いて、光と大気中の粒子の間の相互の影響を計算することにより霧の制限のいくつかを克服する。しかるに、光ビームの一条の光線は見えるようになるだろう、そして、オブジェクトは煙や霧の上へ影を投げるだろう。 大気(atmosphere)の構文は: atmosphere { type TYPE distance DISTANCE [ scattering SCATTERING ] [ eccentricity ECCENTRICITY ] [ samples SAMPLES ] [ jitter JITTER ] [ aa_threshold AA_THRESHOLD ] [ aa_level AA_LEVEL ] [ colour ] } typeキーワードは用いる拡散モデルのタイプを決める。異なるモデルを与える5つの異なるフェーズ(phase)関数がある:等方性(isotropic)、レイリー(Rayleigh)、ミー(Mie)（haze(かすみ)とmurky(くすんだ)大気）および Henyey-Greensteinである。 等方性拡散は方向に依存しないため最も単純な拡散形式である。大気中の粒子により拡散する光の量は視線の方向(viewing direction)と入射光の間の角度に依存しない。 レイリー散乱は空気の分子のようなきわめて小さい粒子による拡散のモデルである。拡散される光の量は入射光の角度に依存する。入射光が視線に平行あるいは反対の平行(anti-parallel)の場合に最大になり、入射光が視線方向に直交している場合に最小になる。POV-Rayで用いられているレイリーモデルでは拡散の波長への依存性は考慮されていない点に注意して下さい。 図 レイリー拡散関数。 ミー散乱は霧の小さな水滴、雲の粒子および汚染された空の反応する粒子のように相対的に小さい粒子に使われる。このモデルでは拡散は非常に前方への指向性がある。すなわち、拡散光の量は入射光か視線方向に反対の平行の時最大となる(光が直接観察者に来るとき)。入射光が視線方向に平行なとき最小になる。hazeおよびmurky大気モデルは拡散特性が異なる。murkyモデルはhazeモデルよりもより方向性が高い。 図 ミー"haze"拡散関数。 図 ミー"murky"拡散関数。 Henyey-Greenstein拡散は解析的関数に基づいていて、非常に多様な異なる拡散タイプをモデル化するために用いられる。その関数は与えられた離心率(eccentricity)eの楕円をモデル化する。この離心率は拡散タイプ5にだけ使われるオプショナルなキーワードeccentricityで指定される。eccentricity値0は等方性拡散を定義し、正の値は光の方向に拡散を導き、負の値は光の反対方向に導く。より大きなeの値は(負の場合はより小さな値)拡散の指向性を増加させる。 図 異なるeccentricity値に対するHeyney-Greenstein拡散関数。 それぞれの拡散タイプを用いる最も簡単な方法は、いくつかの定数を宣言し。それらを大気の定義の中で使うことである: #declare ISOTROPIC_SCATTERING = 1 #declare MIE_HAZY_SCATTERING = 2 #declare MIE_MURKY_SCATTERING = 3 #declare RAYLEIGH_SCATTERING = 4 #declare HENYEY_GREENSTEIN_SCATTERING = 5 distance(距離)キーワードは大気中の粒子の密度を決定するために使われる。この密度はすべての大気に対して一定である。このdistanceパラメータはフォグのdistanceと同じ方法で動作する。 scattering(拡散)キーワードで大気により拡散される光の量を変更し、大気の輝度を増加あるいは減少させる。小さいscattering値は輝度を減少させ、大きな値はそれを増加する。 colour あるいは color キーワードは色の付いた大気を作成するために使うことができる。つまり、通過する光をフィルタする粒子を得るために使うことができる。デフォルトの色は黒(black)である。 大気を通過する光(光源あるいは背景から来るもの両方)は指定したカラーのフィルタ値が0でなければ大気のカラーでフィルタされる。言い換えると、大気のカラーで光がフィルタされる量はそのフィルタ値で与えられる(フォグでなされるのと同じ方法でずいぶん多量である)。rgbf <1,0,0,0.25>のカラーを使うとわずかに赤らんだ大気になる。なぜなら大気を通過する光の25%が大気のカラー、つまりrgb <1,0,0>(これは赤)、でフィルタされる(掛けられる)。 大気のカラーの透過(transmittance)チャンネルは最小の半透明性(translucency)を指定するために使われる。ゼロより大きな値が使われた場合、大気がどのくらい密度が高いかによらず大気を通過するその量の背景を見る。これはフォグでなされるように動作する。 大気は視線光線に沿ったサンプリングと光源からの寄与を見ることにより計算されるのでエイリアシングしやすい(まさに、サンプリングテクニックのいずれものように)。見えるかも知れないアーチファクト(不自然なもの)を最小化するための4つのパラメータがある: samples, jitter, aa_level および aa_thresholdである。 samples(サンプル)キーワードは、視線光線に沿った一つの間隔の中でどれくらいのサンプルが計算されるか決める。 間隔の長さはdistanceキーワードで与えられた距離か視線光線の照明された部分の長さのいずれか小さい方である。この照明された部分はもっとも光源で照らされそうな光のセクションである。スポットライトの場合、それは光の円錐の中に存在する光線の一部分である。他の場合はもっと難しくなる。あなたが心にとどめておかなければならないことは、実際のサンプリング間隔の長さは変数であるが指定された間隔では指定したサンプル(samples)より少くなることは決してないだろうということである。 サンプリングアーチファクトの見える程度を減らす一つのテクニックはサンプル点をジッタ(jitter)することである。つまり、それらの位置にランダムノイズを加えることである。これはjitterキーワードでなされる。 別のテクニックはスーパーサンプリング(一つのアンチエイリアシング法)である。これは大きな輝度変化が起きている場所(例えば影の縁)に付加的なサンプルを追加することによりフィーチャーが欠落するのを避ける手助けとなる。アンチエイリアシングはaa_levelキーワードでonに切り換えられる。もしこれが0より大きければスーパーサンプリングが使われる。付加的サンプルは高い輝度変化の伴う2つのサンプルの間に再帰的にとられる。細別(subdivision)がなされる場所のレベルはaa_levelキーワードで指定される。レベル1は1回の細別(１付加サンプル)を意味し、レベル2は2回の細別(3つまでの付加サンプル)を意味し、以下同様である。 輝度の変化のしきい値はaa_thresholdキーワードで指定される。もし輝度の変化がこのしきい値よりも大きければ、アンチエイリアシングがそれら2つのサンプルに対して用いられる。 スポットライトでは、その光の円錐が見えるようになるので最高の結果を作成することが可能である。点光では霧の中の街灯のような効果を作成するのに使える。光源にatmosphere offを加えることにより光を大気と影響し合わなくすることができる。それらはシーンをよりリアリスティックに見せるために、シーン全体の光のレベルを増加させるために使うことができる。 この大気の機能はカメラが中空でない(non-hollow)オブジェクトの内側にある場合は働かない点に注意しなければならない(詳しい説明については「中空および中実オブジェクト」を参照)。 7.7.2 背景(Background:バックグラウンド) 必要であれば背景色(バックグラウンドカラー)を指定できる。オブジェクトに当たらなかった光はすべてこの色に色づけられる。デフォルトの背景は黒(black)である。背景(background)の構文は: background { colour <カラー> } 7.7.3 フォグ(Fog:霧) フォグ(Fog)は以下の構文で定義される: fog { fog_type フォグタイプ distance 距離 colour <カラー> [ turbulence <動乱> ] [ turb_depth 動乱深さ ] [ omega オメガ ] [ lambda ラムダ ] [ octaves オクターブ ] [ fog_offset フォグオフセット ] [ fog_alt フォグ高さ ] [ up <フォグ上方向> ] [ 変換 ] } オプションのupベクトルは上方を指す方向を指定し、一般にカメラの上方向(up)ベクトルと同じである。グラウンドフォグ(ground fog)の評価の間になされるすべての計算はこのupベクトルに相対的になされる。つまり、実際の高さこのベクトルに沿って計算される。 upベクトルはまた「変換」で説明したご存じの任意の変換により修正することができる。upベクトルを拡大縮小することはあまりいい考えではないけれども - 結果がほとんど予測できないので - 回転させることができることはとても役に立つ。また、平行移動はup方向には影響しない(そしてフォグに影響しない)ことに注意して欲しい。 現在2つフォグのタイプがある。コンスタントフォグ(constant fog:一定霧)とグラウンドフォグ(ground fog:地上霧)である。コンスタントフォグはどこでも一定の密度を持ち、グラウンドフォグはup軸上の与えられた点以下の高さでは一定の密度を持ち、その軸に沿って薄くなる。それ以下ではフォグが一定密度になる高さはfog_offsetキーワードで指定する。fog_altキーワードはフォグが消えて行く割合を指定する。fog_offset+fog_altの高度で霧は、25 %の密度を有する。与えられた高さyでの霧の密度は、公式によって計算される： / | 1 | ------------------------------------, y > fog_alt | (1 + (y - fog_offset) / fog_alt) ^2 密度 = -| | | 1, y <= fog_alt | \ 光線に沿った総密度は、起点の高さから終点の高さまで積分されることによって計算される。 2つの定数がフォグタイプの使用を容易にするためにファイルconst.incで定義されている: // フォグタイプの定数(FOG TYPE CONSTANTS) #declare Constant_Fog = 1 #declare Ground_Fog = 2 交差深さ(intersection depth)dを持つピクセルのカラーは C_pixel = exp(-d/D) * C_object + (1-exp(-d/D)) * C_fog で計算される。ここで D はフォグ距離(fog distance)である。深さ 0 では最終的なカラーはオブジェクトのカラーである。もし交差深さがフォグ距離と等しければ、最終的なカラーはオブジェクトのカラーが64%でフォグのカラーが36%となる。 colorキーワードで与えられるフォグのカラーには三つの目的がある。第１にフォグと背景を交合するために使われるカラーを定義する。第２に半透明性のしきい値を指定するのに使われる。透過(transmittance)にゼロより大きな値を使うことによって、少なくともその量の光がフォグを通して見えるようにすることを確実にすることができる。0.3の透過では少なくとも30%の背景が見える。第３にフィルタリングフォグをを作るために使われる。ゼロより大きなフィルタ値を使うことによって、フィルタ値で与えられた背景光の量がフォグのカラーに掛けられる。0.7のフィルタ値は70%の背景光をフィルタし、30%をフィルタしないままにするフォグにする。 フォグは階層化することができる。すなわちあなたの望むだけたくさんの背後の層を適用することができる。一般に、各層が異なる色と高さで、異なる動乱(turbulence)値のグラウンドフォグの場合最も効果的である。フォグの階層を用いるためには単にそれらをシーンに加えればよい。 動乱を加えることによりオプションでフォグをかき混ぜても良い。turbulenceキーワードには用いる動乱の量を指定する浮動小数点数あるいはベクトルが続く。omega、lambdaおよびoctavesの動乱パラメータもまた指定することができる。これらすべての動乱パラメータについてはセクション「パターン修飾子」を見て欲しい。 これらに加えて、フォグの動乱(fog turbulence)は視線光線に沿った方向にturb_depthの量を用いて拡大縮小しても良い。代表的な範囲は0.0 から 1.0まであるいはそれ以上である。デフォルト値は 0.5 であるが任意の浮動小数点数値を使って良い。 カメラが中空でない(non-hollow)オブジェクト内にある場合はフォグ機能は働かない点に注意して欲しい(詳しい説明は「中空および中実オブジェクト」を参照して欲しい)。 7.7.4 天球(Sky Sphere) 天球(sky sphere)は空をシミュレートするために球を追加する必要なく、リアリスティックな空の背景を作成するために使われる。 構文は: sky_sphere { pigment { ピグメント1 } pigment { ピグメント2 } pigment { ピグメント3 } ... [ 変換 ] } 天球はいくつかのピグメント層を持つことができる。最後のピグメントが最上位、つまり最後に評価され、最初のピグメントが底に、つまり最初に評価される。もし、上位の層がフィルタあるいは透過成分を持つ場合、下位の層はそれを通り抜けて光る。そうでなければ下位の層は見えない。 天球はピグメントパターンを評価するためのパラメータとして方向ベクトル(direction vector)を用いて計算される。このことにより結果は視点に依存しなくなるので、これは空までの距離が見えるオブジェクト間の距離よりも非常に大きい実際の空のかなり良いモデルである。 もし、素晴らしい色の混合を背景に加えたい場合、それを以下の例を用いて簡単に行うことができる。 sky_sphere { pigment { gradient y color_map { [ 0.5 color CornflowerBlue ] [ 1.0 color MidnightBlue ] } scale 2 translate -1 } } これは天頂でのコーンフラワーブルー(CornflowerBlue)から地平線でのミッドナイトブルー(MidnightBlue)までの柔らかな混合になる。拡大縮小(scale)および平行移動(translate)操作が、<-1, -1, -1>から<1, 1, 1>までの範囲にある方向ベクトル値を<0, 0, 0>から<1, 1, 1>までにマップするために使われる。こうして、地平線以下の空の部分での色の混合の繰り返しは避けられる。 簡単に天球をアニメーション化するために「変換」で述べた既知の変換を使うことができる。結果がほとんど予測できないため、天球を平行移動および拡大縮小するのはあまり良い考えでないかも知れないが、回転ができることはとても役に立つ。アニメーションでは、例えば空の色の混合で昇る太陽を追跡することができる。 いずれのシーンにおいても天球は一つだけが使えることに注意すべきである。また、正射投影(orthographic)あるいは円筒カメラのようなカメラタイプを使う場合は、期待通りにはうまく働かないだろう。正射投影カメラは平行な光線を使うので、天球の非常に小さな部分しか見えない(ほとんどの場合一色の空が見えるだけである)。けれど曲面での反射はうまく働く。つまりミラーボールの中ならその空をはっきりと見るだろう。 7.7.5 虹(Rainbow) 虹(rainbow)はフォグのような、円弧であり虹を作成するために使うことができる。構文は: rainbow { direction <方向> angle 角度 width 幅 distance 距離 color_map { カラーマップ } [ jitter ジッタ ] [ up <上方向> ] [ arc_angle 弧の角度 ] [ falloff_angle 減退角度 ] } 方向(direction)ベクトルは虹に対して応答する(仮想)光の方向を決める。理想的にはこれは平行光線を放射する太陽のような無限に遠い光源である。虹の位置と大きさは、angle(角度)とwidth(幅)キーワードによって指定される。それらがどのように働くか理解するために、あなたは最初に、虹がどのように計算されるか知らなければならない。 それぞれ光線のために虹の方向ベクトルと光線の方向ベクトルの間の角度が計算される。もしこの角度が"角度-WIDTH/2" から "角度+WIDTH/2"までの間にある場合、光線が虹に当たる。その角度を虹のカラーマップへのインデックスとして用いることによりカラーが決定される。カラーが決定された後、それはフォグの場合と同様に背景色と混ぜられる。 このように角度(angle)および幅(width)パラメータはその角度以下では虹の見える角度を決定する。オプションのjitterキーワードはインデックスにランダムノイズを加えるために使うことができる。これは虹にいくらかの不規則性を加え、より現実的に見せる。 distanceキーワードはフォグで使われるものと同じである。虹はフォグのような効果であるから、虹はオブジェクトの上に見えることが可能である。もしこの効果が望むものでなければ、大きなdistance値を使うことにより避けることができる。この効果が起こらないことを確実にするためにデフォルトで十分に大きな値が使われる。 color_mapキーワードは虹にマップされるカラーマップを割り当てるために使われる。現実的な虹の作成を可能とするために、カラーマップへのインデックスは光線と虹の方向ベクトルの間の角度とともに増加することを知っておくことは重要である。最も内側の輪ではインデックスはゼロであり、最も外側の輪では1である。カラーマップ内のカラーのフィルタと透過値はフォグで使われるものと同じ意味を持つ。(セクション「フォグ」参照)。 デフォルトの虹は360度の弧であり円のように見える。これは地平面(ground plane)がある場合は問題がない。それは虹の見えない部分である低い部分を隠す。そうでない場合、あるいは全部の弧が見えるのを望まない場合、短い弧を指定するためにオプションのキーワードup、arc_angleおよびfalloff_angleを使うことができる。 arc_angle(弧角度)キーワードは弧の大きさを度で決める(0から360度までである)。360度より小さな値では弧が突然見えなくなる。これでは素晴らしくは見えないから、虹が滑らかに背景に混合し、柔らかく消滅する範囲を指定するためにfalloff_angle(減退角度)キーワードを使うことができる。減退角度は弧角度以下でなければならない。 upキーワードはゼロの角度の位置が何かを決定する。このベクトルを変更することによりその方向に関して虹を回転させることができる。虹の弧は -ARC_ANGLE/2 から +ARC_ANGLE/2 まででであることに注意しなければならない。ソフトな領域は -ARC_ANGLE/2 から -FALLOFF_ANGLE/2 までと +FALLOFF_ANGLE/2 から +ARC_ANGLE/2 までである。 以下の例は120度の虹の弧を作成する。その減退領域は両端で30度である: rainbow { direction <0, 0, 1> angle 42.5 width 5 distance 1000 jitter 0.01 color_map { Rainbow_Color_Map } up <0, 1, 0> arc_angle 240 falloff_angle 60 } 任意の数の虹が使える。また、それらを他の大気の効果と組み合わせることもできる。 7.8 グローバルな設定(Global Settings) global_settings構文はたくさんのグローバル(大域的な)なパラメーターをかき集めたキャッチオール(catch-all)構文である。この構文は他の構文の内部でなければシーンのどこにあっても良い。シーンの中に複数のglobal_settings構文があっても良い。最後のglobal_settings構文で指定されたどんな値も以前の設定を無効にする。どこで構文を指定するかによらず、その機能は全シーンに適用される。 以前のバージョンのPOV-Rayの言語命令のいくつかの項目はglobal_settings構文の内部に移されたので、それらの効果がグローバルであることがユーザにとってより明らかになった。古い構文も許されるが警告を生ずる。 global_settings { adc_bailout 浮動小数点数 ambient_light カラー assumed_gamma 浮動小数点数 hf_gray_16 ブーリアン irid_wavelength カラー max_intersections 整数 max_trace_level 整数 number_of_waves 整数 radiosity { ラディオシティー項目... } } 各項目はオプションであり任意の順序で現れて良い。一つの項目が二度以上指定された場合、最後の設定がそれ以前の値を無効にする。各項目の詳細が以下のセクションで与えられる。 7.8.1 ADC_Bailout(適合深さ制御_からの脱出) 多くの反射および透明な表面を持つシーンでは、特定のピクセルの色にごく僅かに寄与する複数の反射および屈折のトレーシングでPOV-Rayは動きがとれなくなる。付加的な反射および屈折光の計算をそれらの寄与が取るに足らなくなったときに停止するために、プログラムは適合深さ制御(Adaptive Depth Control(ADC))と呼ばれるシステムを呼び出す。 ある光線の寄与が取るに足らないとみなされる点を指定するために、浮動小数点数が続くadc_bailoutキーワードのグローバル設定を使うことができる。 global_settings { adc_bailout 浮動小数点数 } デフォルト値は1/255あるいは近似的に0.0039である。これは24bitイメージにおいてはそれより小さい変化は見ることができないからである。一般にこの設定は十分に適切であるので、そのまま残しておくべきである。adc_bailoutを0に設定するとADCは無効になり、生み出される光線の数の上限を設定するmax_trace_levelを完全にあてにすることになる。 (訳注:サンプルはpov3demo\other\adctest.pov参照) 7.8.2 環境光(Ambient Light) 環境光(Ambient light)は部分的にあるいは完全に影の中にある照明領域に責任を持つ相互拡散反射をシミュレートするために使われる。POV-Rayは、すべての仕上げ(finish)構文の中のambient値を変更することなく、環境光の照明の輝度を簡単に変えることができるように環境光源を提供する。また環境光源のカラーを変更することにより面白い効果を作成することができる。構文は: global_settings { ambient_light カラー } デフォルトは白色の環境光源がrgb <1,1,1>で設定される。実際に使われる環境光は: AMBIENT = FINISH_AMBIENT * GLOBAL_AMBIENT 7.8.3 Assumed_Gamma(仮のガンマ) 多くの人々は、システムで表示されるいくつかのイメージが、ある時と別の時で明るすぎたり薄暗かったりすることに気づいたことがあるかも知れない。概して、マッキントッシュユーザーはPCで作られたイメージがあまりに明るすぎ、PCユーザーはマッキントッシュで作られたイメージがあまりに薄暗いのに気が付く。 assumed_gamma(仮のガンマ)グローバル設定はDisplay_Gamma INI設定に関連して働き(セクション「ディスプレイハードウェア設定」参照)、POV-Rayが使われているハードウェアプラットホームの幅広い変化にわたってシーンファイルが同じ仕方で表現されることを保証する。仮のガンマ設定は、シーンファイルの中で、 global_settings { assumed_gamma 浮動小数点数 } を付け加えることによって用いられる。ここで仮のガンマ(assumed gamma)値は、ピクセルが表示されるあるいはディスクにセーブされる前に適用される訂正係数である。POV-Rayの昔のバージョンで作成されたシーンのために、仮のガンマ値はシーンが作成されたシステムのディスプレイガンマ値と同じものだろう。PCシステム用のほとんどの普通のディスプレイガンマは2.2であり、マッキントッシュシステム上で作成されたシーンのためには1.8のシーンガンマを使わなければならない。シーンで時々起こる他のガンマ値は1.0である。 互換性上の理由により、assumed_gammaグローバル設定を持たないシーンはガンマ補正が実行されない。あなたが新しいシーンを作成しているか、古いシーンをレンダリングしているならば、適当なassumed_gammaグローバル設定を挿入することを強く勧める。新しいシーンに対しては、光が現実の世界の中でどのようによりリアリスティックに現れるかをモデル化するために、仮のガンマ値に1.0を使うべきである。 続いているセクションでは、より徹底的に、ガンマが何であるか、そしてそれがなぜ重要かを説明する。 7.8.3.1 モニタガンマ(Monitor Gamma) どのようにイメージが表示されるかの差は、どうのようにコンピュータが実際イメージを受け取りそれをモニタに表示するかの結果である。イメージをレンダリングし、それをスクリーンに表示するプロセスの中で、POVシーンファイルあるいはイメージファイルガンマとモニタガンマを含むいくつかのガンマ値が重要である。 POV-Rayによって生成されたほとんどのイメージファイルはピクセルの赤、緑、青成分のそれぞれのために0から255までの範囲の数を保存する。それらの数は0が黒で255が最も明るい色である(いずれも100%の赤、100%の緑あるいは100%の青)各色成分の輝度を与える。イメージが表示されるとき、グラフィックスカードはそれぞれのカラー成分を電圧に変え、それはスクリーン上の赤、緑、青の蛍光体を明るくするためにモニタへ送られる。電圧は、通常それぞれカラー成分の値への比例項である。 最大あるいは最小でない可能な値の強度を表示しているときガンマは重要になる。例えば0から255の間の数でピクセルが保存された場合、127は最大輝度の50%を表さなければならない。ガンマ補正をしないシステムでは127は最大電圧の50%に変換される。しかしモニタを動作させる蛍光体と電子銃の方法のため、これはガンマ2.2のモニタでは最大色輝度の22%にしかならない。このモニタで最大輝度の50%のピクセルを表示するためには最大電圧の73%の電圧が必要であり、これはピクセル値186の保存に変換される。 入力ピクセル値と表示される輝度の間の関係はある指数関数で近似できる。 obright = ibright ^ display_gamma ここでobrightは出力輝度でibrightは入力ピクセルの輝度である。両方の値は0から1(0% から 100%)の範囲である。ほとんどのモニタは1.8から2.6の範囲の固定ガンマ値を持つ。display_gammaと上の式を用いて、1より大きな値は出力輝度は入力輝度より小さくなることを意味する。出力と入力輝度を等しくするために、1の全システムガンマが必要である。これを行うために、上と同じ方法の入力輝度のガンマ補正が必要であるが、ガンマ値はモニタに送る前に1/display_gammaにする。ディスプレイガンマ2.2を補正するためには、このプレモニタガンマ補正(pre-monitor gamma correction)ではガンマ値1.0/2.2あるいは近似的に0.45を用いる。 プレモニタガンマ補正がどのようになされるかは、用いているハードウェアとソフトウェアに依存する。マッキントッシュではオペレーティングシステムはディスプレイハードウェアからアプリケーションを切り離すためにそれ自身にそれをとった。ガンマコントロールパネルを通してユーザーは実際のモニタガンマを設定しても良く、MacOSは全ピクセルの輝度を変換する。そのためモニターは指定されたガンマ値を持つように見えるだろう。シリコングラフィックスのマシンでは、ディスプレイアダプタが、望まれる全ガンマ(デフォルトは1.7)を与えるモニタに調整された組み込みガンマ補正を持つ。残念なことに、PCとほとんどのUnixシステムでは、必要なガンマ補正をするためのアプリケーションまである。 7.8.3.2 イメージファイルのガンマ(Image File Gamma) ほとんどのPCとUnixアプリケーションとイメージファイルフォーマットはディスプレイガンマを理解しないので、それを補正するために何もしない。その結果、これらのシステムでイメージを作成しているユーザーは、表示されるときに正しい輝度になる方法でイメージを調整する。このことはファイルに保存されるデータ値はモニタの暗くなる効果を補うためにより明るく作成されることを意味する。本質的には、これらのシステムで作成され保存されたイメージファイルに0.45のガンマ補正が組み込まれる。これらのファイルがマッキントッシュシステムで表示された場合、ガンマ補正がファイルに組み込まれているのに加えてMacOSに組み込まれたガンマ補正によりイメージはあまりに明るくなるだろう。同様にマッキントッシュやSGIシステムで正しく見えるファイルは、PCで表示されるとき、組み込みガンマ補正のためにあまりに暗いだろう。 POV-Ray 3.0によって生成された新しいPNGフォーマットファイルは、POV-Rayで作成された場合PNGファイル内部にイメージファイル・ガンマ(それは1.0/display_gammaである)を保存することよって、多すぎたり十分でないガンマ補正の問題を克服する。PNGファイルが後に正しくセットアップされたプログラムで表示される場合、イメージをもしかすると異なる作成時のもともとのディスプレイガンマに対して補正するために現在のディスプレイガンマと同様にこのガンマ値が使われる。 残念なことに、POV-Rayのサポートするすべてのイメージファイルフォーマットの中で、PNGはガンマ補正機能を持つ唯一のものであり、それで幅広い種類のプラットホームで表示されるイメージのためにむしろ好まれる。 7.8.3.3 シーンファイルのガンマ(Scene File Gamma) イメージファイルのガンマの問題はそれ自身、まさしくシーン自身がPOV-Rayでどのように生成されるかの結果である。あなたが新しいシーンを始めて、光源を置いて、表面のテクスチャとカラーを調整しているとき、あなたの好きなように照明する前に一般にいくつかの試みを作成する。あなたがこれらの設定をどのように選択するかはプレビューイメージあるいはディスクに保存されたイメージファイルに依存する。それは言い換えると、使われているディスプレイハードウェアの全ガンマに依存する。 このことは、あなたがPOV-Rayシーンファイルの中で芸術家のようにあなたの特定のハードウェアのためにガンマ補正していることを意味する。このシーンファイルはまたあなたのハードウェアのためにガンマ補正され、あなた自身のものと同様のシステムでは正しく表示されるイメージファイルを作成する。しかし、このシーンが別のプラットホーム上でレンダリングされるとき、用いられた出力ファイルフォーマットに関係なくそれはあまりに明るいかもしれないし、あまりに薄暗いかもしれない。一つの固定されたガンマ値を持つようにすべてのシーンファイルを変更する代わりに(天国への出入りは禁止された!)、POV-Ray 3.0はシーンファイルが作成されたシステムのディスプレイガンマ値をシーンファイル内に指定することを可能にする。 assumed_gammaグローバル設定は、Display_Gamma INI設定に関連して与えられたシーンでどのようにガンマ補正をするかをPOV-Rayに知らせ、プレビューおよび出力イメージファイルはいずれのシステムでも正しい輝度を示す。ガンマ補正はPOV-Rayの内部的になされるため、どんな出力ファイルフォーマットが使われたかによらず現在のディスプレイに対して正しい輝度の出力イメージファイルを作成する。また、ガンマ補正がPOV-Rayが内部的に用いる高精度のデータフォーマットでなされるために。ファイルがディスクに書き込まれてからなされるガンマ補正に比較してより良い結果を生む。 assumed_gamma設定のある場合とない場合でのシステムの出力の違いは注意しなくても良いけれども、仮のガンマはシーンがかつて他のプラットホームでレンダリングされた場合は重要である。 7.8.4 HF_Gray_16(ハイトフィールドの16階調グレイ) hf_gray_16の設定は他のPOV-Rayシーンでの使用のためのハイトフィールドを生成するためにPOV-Rayを使う場合に便利である。構文は... global_settings { hf_gray_16 ブーリアン } ブーリアン値はオプションのonあるいはoffを切り換える。ブーリアン値なしでこのキーワードが指定された場合オプションはonに切り替わる。もしシーンのどのglobal_settings構文にもhf_gray_16が指定されない場合のデフォルトはoffである。 hf_gray_16がonの場合、出力ファイルはハイトフィールドの形式になり、任意の点の高さはピクセルの輝度に依存する。ピクセルの輝度はカラーイメージがグレイスケールイメージに変換されるのと同じ方法で計算される: height = 0.3 * red + 0.59 * green + 0.11 * blue hf_gray_16オプションの設定はそれが使われた場合、プレビュー表示をカラーの代わりにグレイスケールにする。いくつかのファイルフォーマットはハイトフィールドの保存に後で理解するのが難しい方法で保存するので、ハイトフィールドがどのように見えるかを理解するのを可能にする。POV-Rayのハイトフィールドが各ファイルタイプでどの様に保存されるかの説明はセクション「ハイトフィールド」を見て欲しい。 7.8.5 Irid_Wavelength(虹色の光彩の波長) 虹色の光彩の計算は、赤、緑および青い光の原色の支配的な(dominant)波長に依存する。あなたは、次のようにグローバル設定 irid_wavelengthを用いて値を調節することもできる... global_settings { irid_wavelength カラー } デフォルト値は rgb<0.25,0.18,0.14> で、フィルタ及び透過値は無視される。これらの値は光の波長に比例するが、それらは、現実の世界の単位を表さない。 一般に、デフォルト値が適切だと判明するはずであるが、我々は他の値で実験するための意味でこのオプションを提供する。 7.8.6 Max_Trace_Level(最大トレースレベル) 多くの反射および透明な表面を持つシーンでは、特定のピクセルの色にごく僅かに寄与する複数の反射および屈折のトレーシングでPOV-Rayは動きがとれなくなる。グローバル設定max_trace_levelはPOV-Rayが光線を追跡する再帰レベルの最大数を定義する。 global_settings { max_trace_level 整数 } 光線が反射されるか、透明なオブジェクトを通り抜けているとき、そして影光線(shadow rays)が投げられるときにこれは用いられる。光線が反射する表面に当たるとき、その点が何を反射するかを見るために、他の光線が生み出される。これがトレースレベル1である。それが別の反射する表面にあたるならば、別の光線が生み出されトレースレベル2に向かう。最大レベルは、デフォルトで5である。 POV-Rayのバージョン3.0の中で付け加えた速度向上の一つが、適合深さ制御（ADC）である。反射あるいは屈折による結果、新しい光線が生み出される度毎に、そのピクセルの全カラーへの寄与は反射量および屈折表面のフィルタ値で減少させられる。いくつかの点で、この寄与は取るに足らないものとみなされ、さらなる光線の追跡をする点はなくなる。適合深さ制御は、この寄与を追跡し、いつ脱出するかを決めるものである。部分的に反射あるいは屈折するたくさんの表面を使うシーンにおいてこれは、発射される光線のかなりの減少を生み、より高いmax_trace_level値の使用をより安全にすることができる。 カラー寄与でのこの減少は各表面の反射量あるいはフィルタ値によるスケーリングの結果である。したがって、完全な鏡面あるいは完全に透明な表面はADCで最適化されない。あなたは統計画面のRays Saved および Highest Trace Levelを見ることによりADCの結果を見ることができる。 光線の寄与が取るに足らないとみなされる点は、adc_bailout値によって制御される。デフォルトは、それより小さい値の変化を24ビットイメージでは見ることができないので1/255かおよそ0.0039である。一般にこの設定は完全に適切であるのでそのままにしておくべきである。adc_bailoutを0に設定するとADCは無効になり、生み出される光線の数の上限を設定するmax_trace_levelを完全にあてにすることになる。 もし無反射の表面が見つかる前にmax_trace_levelに届いた場合、もしADCが光線木からの早めの脱出を許さなければ、そのカラーは黒を返す。色が付くべき反射する表面に黒い領域が見える場合はmax_trace_levelを上げなさい。 あなたが見る可能性があった他の症状が、透明なオブジェクトとともにある。事例として、同心球の結合(union)をクリア(透明)なテクスチャで作ってみよう。その結合(union)を半径1から10までの10個で作りレンダリングしよう。そのイメージは最初のいくつかは正確だがその後黒になる。これは透明な表面を通過するたびに新しいレベルが使われるためである。この問題を修正するためにはmax_trace_levelを上げて下さい。 注意:max_trace_levelを引き上げることはより多くのメモリを使い、ADCはこれを大きい範囲で減少させるだろうけれども、スタックオーバーフローによるエラーでプログラムのクラッシュを引き起こす。max_trace_levelに対する値は制限されないので時間とメモリの許す限り任意の値を設定できる。しかし、もしそのような深さがシーンにとって実際に必要とされなければ、その設定を増加させることは、増やされるメージ品質に必ずしも匹敵しない。 7.8.7 Max_Intersections(最大交差数) POV-Rayは、一そろいの内部スタックを光線/オブジェクトの交差点を集めるために用いる。これらのI-Stacksの中の項目の通常の最大数は64である。複雑なシーンによって、これらのスタックがあふれるようになるかもしれない。POV-Rayは止まらない、しかし、それはあなたのシーンを間違ってレンダリングする可能性がある。POV-Rayがレンダリングし終わるとき、たくさんの統計量が表示される。あなたがI-Stack Overflowsが統計値で報告されるのを見るならば、スタックの大きさを増加させなければならない。あなたのシーンに次のようにグローバルな設定を付け加えて下さい： global_settings { max_intersections 整数 } 7.8.8 Number_Of_Waves(波の数) 波(wave)と波紋(ripples)パターンは、それぞれわずかに異なる中心と大きさで一連の波を合計することによって生成される。デフォルトで10の波が合計されるが、この量はnumber_of_waves設定を変えることによって包括的に制御することができる。 global_settings { number_of_waves 整数 } この値を変更することは、シーン内のすべてのパターン上に同様に、波および波紋両者に影響を及ぼす。 7.8.9 ラディオシティ(Radiosity) 重要な注意:POV-Ray 3.0のラディオシティの機能はいくぶん実験的なものである。これらの機能の設計とインプリメンテーション(実現)は将来のバージョンで変更される可能性が高い。我々は、3.0でこれらの機能を用いているシーンが、今後のリリースで同じくレンダリングできるか、あるいは言語構文の後ろ向き互換性を完全に維持することができるかどうかを約束することができない。 ラディオシティはよりリアリスティックに拡散相互反射光を計算する特別な計算である。この拡散相互反射は、もしすべて青いカーペットで、青い壁で青いカーテンの部屋に白い椅子を置くと見ることができる。その椅子は部屋の他の部分から反射する光から青い色合いをピックアップするだろう。また、光源が直接その表面を照らさなくても周囲の陰になった領域がすっかりは暗くならないことも気が付いて欲しい。他のオブジェクトから反射する拡散光は影の中を満たす。典型的に、レイトレーシングはそのような効果をシミュレートする環境光(ambient light)と名づけられるトリックを使うが、それはあまり正確ではない。 ラディオシティは単純化された環境光よりもより正確であるが計算にはとても長く時間がかかる。このため、POV-Rayはデフォルトではラディオシティを使わない。ラディオシティはRadiosity INIファイルオプションあるいは+QRコマンドラインスイッチでonに切り換えられる。 以下のセクションではラディオシティがどう働くか、グローバル設定を用いてどのようにコントロールするかと品質とスピードの交換の手引きを述べる。 (訳注:ラディオシティのサンプルはpov3demo\radiosにある。) 7.8.9.1 ラディオシティーがどのように働くか(How Radiosity Works) レイトレーシングの問題は、あなたがシーンの中に見ることができる各点での光のレベルがどうかを表すことである。伝統的にレイトレーシングでは、これは、以下の構成要素の和になるように分解できる。 - 拡散(Diffuse)、物体の光に面した部分の面を明るくする効果; - 鏡面(Specular)、光る物体がdings(くすみ:dingy?)あるいは光沢(sparkles)を持つ効果; - 反射(Reflection)、鏡のような効果;および - 周囲／環境(Ambient)、すべてのシーンが持つ全体的な至る所にある光のレベルで、影の中の物体が真っ黒になることから守る。 (訳注:以下本節は内容、英文とも難解であり、訳者は翻訳結果に特に自信なし) POVのラディオシティシステムは、Greg Wardの方法に基礎を置き、最後の項(一定の環境光の値)を、どの表面が近くにあるか、それらが交互にどのくらい明るいかに基づく光のレベルで置き換える方法を提供する。 あなたがこの定義について最初に気づくかも知れないことは、それが循環性であることであろう: すべての光は、他のすべてに依存し、また逆もいえる。このことは現実の生活の中では真実であるが、レイトレーシングの世界で我々は近似を作成することができる。用いられる近似は以下の通りである:あなたが注目しているオブジェクトは、近くにある他のオブジェクトをチェックすることにより、あなたに対して計算された環境光(ambient)項を持つ。しかし、この処理の間、それらのオブジェクトがチェックされるとき、伝統的な一定の環境光(ambient)項が用いられる。 どのように、POV-Rayはそれぞれ点のために環境光(ambient)項を計算するか？多くの異なる方向により多くの光線を放って、結果を平均することによってである。典型的な点では、正しくその環境光レベルを計算するために少なくとも200の光線を使うかもしれない。 これはそれがレートレーサーを200倍遅くする様に聞こえるだろう。そのソフトウェアが、環境光のレベルがとてもゆっくり変化するという長所を持つことを除いてはこれは事実である(影は別々に計算され、鋭い影のふちは問題ではないことを思い出して欲しい)。したがって、これらの特別な光線はある間で一度だけ放たれる(だいたい50回に1回)。そしてそれらの計算された値は保存され、可能であればイメージ内の近くのピクセルのために再利用される。 値を保存し再利用するこの処理が各種の調整パラメータの必要性を生じさせ、あなたの求めるように見えるシーンを得ることができる。 7.8.9.2 ラディオシティーの調整(Adjusting Radiosity) 最初に述べたように、ラディオシティはRadiosity INIファイルオプションあるいは +QR コマンドラインスイッチによりonに切り換えることができる。けれどもラディオシティは以下のように global_settings {... }構文内のradiosity {... }構文で指定される多くのパラメータを持つ: global_settings { radiosity { brightness 浮動小数点数 count 整数 distance_maximum 浮動小数点数 error_bound 浮動小数点数 gray_threshold 浮動小数点数 low_error_factor 浮動小数点数 minimum_reuse 浮動小数点数 nearest_count 整数 recursion_limit 整数 } } それぞれの項目はオプションで現れて命令しても良い。ある項目が2度以上指定された場合、最後の設定が以前の設定を上書きする。各項目の詳細を以下のセクションで与える。 7.8.9.2.1 brightness(輝度) これは、システムの残りの部分に上向きに返される前に輝かせられるambient値の程度である。もしあるオブジェクトが 赤 <1, 0, 0>でambient値0.3であれば、普通の状況では赤成分の0.3が加えられる。ラディオシティがonでは、灰色<0.6, 0.6, 0.6>のオブジェクトで囲まれているものと仮定される。集積処理によって返される平均のカラーは、同じものであるだろう。これはテクスチャのambientの重み値0.3が掛けられ<0.18, 0.18, 0.18>が返される。これは通常加えられる0.3よりも暗くなる。その結果、すべての返される値は計算値の平均値の逆数で輝かされ、加えられる平均ambienは変化しない。いくつかは指定されたものより高いだろう(この例では0.3よりも高い)。そしていくつかは低いだろうがシーン全体では輝度は変化しない。 7.8.9.2.2 count(カウント) 新しいラディオシティ(radiosity)値が計算されなければならないときに放たれる光線の数はcount(カウント)で与えられる。100から150の値がほとんどのシーンを良く見えるようにする。より高い値はシーンに対して光のレベルの間の高いコントラストあるいは照明を引き起こす光の小さいパッチを必要とするかもしれない。これはまさしくその集中的な計算なので最終レンダリングのみに使われる。ほとんどのシーンがambient値を1%から2%のピクセルで計算するので、レンダリング時間はこの値の1%から2%倍だけ長くなる。もし300をセットすると、レンダリング完了まで3〜6倍の時間がかかる(1% 〜 2%の300倍)。 この値が低すぎる場合、光レベルは少々しみのよう(blotchy)に見える傾向があり、まるであなたが見ている表面がわずかに反っているように見える。もしそれがあなたのシーンにとって(バンプマップあるいは強いテクスチャを持つ場合のように)重要でなければ、必ず低めの値を使いなさい。 7.8.9.2.3 distance_maximum(距離の最大) distance_maximumは、シーンの中でオブジェクトの大きさに依存する唯一の調整値である。これは正しくレンダリングするためにシーンにセットされなければならない...残りは最初の試しにおいては無視させることができる。簡単にこの意味を記述することは難しい。しかしこれはエラーが100%ヒットすることが保証される（radiosity_error_bound >=1）サンプルからの距離をモデル単位で設定する:サンプルは、それらのオリジナルの計算点からこれより大きい距離では再利用されない。 テーブルの左のふちのリンゴを想像しなさい。目的はリンゴに近すぎず明確にリンゴの下でない右のテーブルの表面のサンプルが使われないことを確かめることである。もし十分な光線がある場合はそれらの一つがリンゴに当たることを保証し、再利用半径を正しくセットするため問題は生じない。実際問題として、あなたはこれを制限しなければならない。 我々は、このテクニックを使う：あなたのシーンの中で、以下の問題を持つかもしれないオブジェクトを見つける：そばに良い環境光が欲しい大きい平らな表面上の小さいオブジェクト。それからどれくらい離れて光線の一つがそれに当たる十分なチャンスを持つかを確かなものとしなければならないか？テーブルの上のリンゴの例では、1POV-Ray単位を1インチと仮定すれば、30インチを使うかも知れない。理論的な探測法(sound way)では(あなたがたくさんの光線を実行しているとき)このオブジェクトの頂上があなたの考えているサンプル点の地平線より5度上の距離である。これはだいたいオブジェクトの高さの11倍に対応する。したがって3インチのリンゴに対しては33インチが意味をなす。1/3インチ以下でその付近のえんどう豆(pea)の良い動作のためには3インチ、その他、を使いなさい。他の非常にラフな見積もりは、あなたの目の位置とあなたが見ているものの距離の1/3である。その論拠は、もしあなたがその下方のシェーディングを心配するならば、あなたは多分テーブルの上のリンゴから90インチを越えないところに居るということである。 7.8.9.2.4 error_bound(エラーバウンド:誤差境界) error_boundは2つの主な速度／品質の調整値の内の一つである(もう一つはもちろん放たれる光線の数である)。理想世界では、これは必要とされる唯一の値であろう。これは我慢できるエラー(誤差)の分数(fraction)を意味することを示す。例えばもし1にセットされるとアルゴリズムは最後のもののエラーが100%の高さと推定されるまで新しい値を計算しない。 当面、回転(rotation)により引き起こされるエラーを無視すると、平らな表面上では、これは再利用距離の分数に等しい。言い換えるとこれはヒットした最も近い品目までの距離である。もし壁から10インチの床に古いサンプルがある場合、エラーバウンド(error bound)の0.5は壁から約5インチの距離に新しいサンプルを取る。0.5は少し粗い準備用で、0.33は最終レンダリングに適している。0.3よりあまり小さな値は永遠に(時間が)かかる。 7.8.9.2.5 gray_threshold(グレイしきい値) 相互反射拡散光は該当する点のまわりのオブジェクトの関数である。これが何百万もの再帰レベルに再帰的に定義されるので、現実のシーンにおいては、すべての点は少なくともシーンの他の部分により照明される。われわれはこれを計算する余裕がないので、一度だけの跳ね返り(bounce)を行うので、計算される環境光はそれに近いオブジェクトの色に強く影響される。これは色のにじみ(color bleed)として知られ、それが実際に起こるが、この計算法があなたを信頼させるだろう程は多くない(訳注:つまりこの計算法では実際よりも多めになる。)。gray_threshold値はシーンをより信頼できるものにするために少しそれをグレイ(灰色)にする。値 .6 はambient値を、計算された等価なグレイ値の60%に計算し、計算された実際の値の40%を加えることを意味する。0%ではこの機能は何もしない。100%では、あなたは常に色合いのない白／グレイambient光を得る。注意:これは明るさ／暗さを変更しないで、ただ色相(hue)/灰色(grayness)の強度を変更する(HLS用語ではHだけを変える)。 7.8.9.2.6 low_error_factor(低い誤差係数) あなたがそれ以上は必要なく、まさに十分なサンプルを計算すると、わずかにしみのような(blotchy)照明を持つイメージを得るだろう。あなたが欲しいのはほんの少しの余分な散在されたもの(interspersed)であり、そうすれば混合(blending)は素敵で滑らかになるだろう。この解決法は、モザイクプレビューである：ラディオシティー値を計算する際に、それは前もって一度ないしそれ以上イメージを調べる。あなたが2、3の追加されたものを得ることを保証するために、ラディオシティアルゴリズムは最終以前のパスの間エラーバウンディングを低くし、最終パスの直前にそれを元に戻す。この調整値は準備中のイメージのパスの間に落とすエラーバウンドの量をセットする。もし低い誤差係数(low error factor)が0.8でエラーバウンド(error bound)が0.4に設定されている場合、最初のパスの間は実際はエラーバウンド0.32を使い、最終パスでは0.4を使う。 7.8.9.2.7 minimum_reuse(最小再使用) 最小限の有効な半径比率は、minimum_reuseによってセットされる。これはスクリーン幅のfraction(分割or一部分)であり、各サンプル点に対する再使用(reuse)の最小半径をセットする(実際には目からの距離のfractionであるが、両者は大雑把にいえば等しい)。例えば、値が0.02であれば、すべてのサンプルに対する最大再使用半径は、スクリーンの2%に対応する地上距離にセットされる。あなたが地平線に光線を放って、それがあなたの目の位置から100マイル離れた距離で地面にぶつかると考えよう。そのサンプルに対する再使用距離は2マイルにセットされる。これは300*400の解像度では(非常に荒っぽく)8ピクセルに対応する。セオリーは、あなたはシーンのどこでもあらゆる裂け目に至る全ピクセルの値を計算したくない。それは時間がかかりすぎる。これは再使用のための最小のバウンドをセットする。この値が低すぎると、(セオリー内にあるべきである)レンダリングは遅くなり、角の内側が少し粒子が粗くなる。高すぎる設定は、それが再使用されるので、ふちの内側の近くで照明の自然な暗くなりかたを得ないだろう。2%より高い値では、単調なエラーをより多く得始める。リンゴの下の広々としたテーブルの照明を再利用することのようである。 これが単位の無い比率であることを忘れないで下さい。 7.8.9.2.8 nearest_count(最も近いカウント) nearest_count値は新しい補間値を作成するために混合される古いambient値の最大数である。これは常にnの幾何学的に最も近い再使用可能な使用される点である。4より低い値で行うと、ものはずいぶんつぎはぎのよう(patchy)になる。でもこれはデバッギングには良い。割り当てられている配列のサイズから、10を越えないようにしなければならない。 7.8.9.2.9 radiosity_quality(ラディオシティーの品質) 7.8.9.2.10 recursion_limit(再帰の限界) この値は相互反射拡散光を計算するためにどのくらいたくさんの再帰レベルが使われるかを決める。有効な値は1か2である。 7.8.9.3 ラディオシティーの助言(Tips on Radiosity) あなたがあなたの値が計算されているところを見たいならば、radiosity_countをだいたい20までにセットして、radiosity_nearest_countを1にセットして、radiosity_greyを0にセットしなさい。このことはすべてを最大限につぎはぎ(patchy)にして、パッチの間に境界を見ることができるだろう。ほとんどのパッチの中央にラディオシティ計算があるだろう。ボーナスとして、これらを実行するのは速い。radiosity_error_boundを上下に変更しそれがどのように変化させるかを見ることができる。同様にradiosity_reuse_dist_minとmaxを変更しなさい。 特別になめらかな結果を得る一つの方法:サンプルカウント(sample count)をクランクアップしなさい(1300の高さにした)そしてlow_error_factorを0.6ぐらいの小さな値に落とそう。reuse_countを7か8にバンプアップしよう。このことは良い値を得て、それらをより多く得て、最終パスにおいてそれらのより多くの間を補間するだろう。それが二乗の関数のようであるから、忍耐の欠如した人々に対するものではない。もしあなたのblotchiness(しみだらけのもの)があるコーナーのあるいはあるオブジェクトの近くだけであるなら、代わりにエラーバウンド(error bound)を調整しなさい。実行に非常に時間がかかるので、決してほんの少し以上を一度に落としてはならない。 もしあなたのシーンが良く見えて、けれどもあるオブジェクトの近くでは正しく見え、間違った色(オブジェクトから遠くと同様の)の平らな表面上に正しい色(大抵より暗い)のスポットを得るならば、reuse_dist_maxを落としてみなさい。それでもまだうまく働かない場合は、光線カウント(ray count)を100ぐらいに増やして、エラーバウンド(error bound)をほんの少し落としてみて下さい。まだ問題があるのならreuse_nearest_countを4ぐらいに落として下さい。 付録 A 著作権 続くセクションではPersistence of Vision(tm) Ray-Tracer、またPOV-Ray(tm)とも呼ばれる、の法律上の情報とライセンス条項を示す。 （訳注：ライセンスにかかわる配布を行う場合は必ず原文を見てそれに従って下さい。本翻訳を根拠にしないで下さい。法律の専門家が翻訳したものではありません。） 付録 A.1 全般的なライセンスに関する取り決め THIS NOTICE MUST ACCOMPANY ALL OFFICIAL OR CUSTOM PERSISTENCE OF VISION FILES. IT MAY NOT BE REMOVED OR MODIFIED. THIS INFORMATION PERTAINS TO ALL USE OF THE PACKAGE WORLDWIDE. THIS DOCUMENT SUPERSEDES ALL PREVIOUS GENERAL LICENSES OR DISTRIBUTION POLICIES. ANY INDIVIDUALS, COMPANIES OR GROUPS WHO HAVE BEEN GRANTED SPECIAL LICENSES MAY CONTINUE TO DISTRIBUTE VERSION 2.x BUT MUST RE-APPLY FOR VERSION 3.00 OR LATER. ( この注意は、すべての公式あるいはカスタム版のPERSISTENCE OF VISIONファイルに伴わなければならない。削除したり修正してはならない。この情報は世界中での本パッケージの使用に関連する。この文書は、以前の全般的なライセンスおよび配布方針のすべてにとって代わる。特別なライセンスを与えられた個人、会社およびグループは、バージョン2.xを配布し続けてもよい。しかし、バージョン3.00以降については再申請が必要である。 ) 本文書はPersistence of Vision(tm) Ray-Tracer a. k. a POV-Ray(tm)の使用および配布に関連する。すべての公式のPOV-Ray Team(tm)アーカイブの中に含まれるPOV-Rayプログラムソースファイル、実行可能な（バイナリ）ファイル、シーンファイル、ドキュメンテーションファイル、ヘルプファイル、ビットマップおよびINIファイルに適用される。これらのすべてを、ここではソフトウェアとして参照する。 このソフトウェアのすべては、POV-Ray Team(tm)1991,1997が著作権を持つ。フリーウェアとして配布されるけれども、パブリックドメインではない。 著作権で保護されたパッケージは、ここで合意されたライセンスによってのみ、配布および修正可能である。本ライセンスの精神はPOV-Rayを標準のレイトレーサーにすることを促進し、POV-Rayのフルパッケージを無料でできる限り多くのユーザーに与え、POV-Rayのユーザーおよび開発者が利益をとられるのを防ぎ、POV-Rayに接する人々の生活の質を高めることである。 このライセンスが作成されたので、これらの目標を実現することができた。あなたは、この規則に従うために正当に束縛される。しかし我々はあなたが告訴に対する恐怖ではなくむしろ倫理の問題として従うことを望む。 付録 A.2 使用法条項(Usage Provisions) 本許諾はユーザーがこのパーケージに含まれる本ソフトウェアおよび関連するファイルを用いてイメージを作成し表現することを許可する。イメージを作成する目的でこのソフトウェアを使うことは完全に無料である。シーンファイルとそのシーンファイルから作られたイメージの制作者は、かれらの制作したイメージとシーンファイルに関するすべての権利を保持し、商用、非商用のいかなる目的にも使用して良い。 ユーザーはまたinclude、texsampsおよびpov3demoサブディレクトリのシーンファイル、フォント、ビットマップおよびインクルードファイルを彼自身のシーンに使用する権利を有する。そのような許諾はpovscnサブディレクトリのファイルには拡張されない。povscnのファイルはあなたの楽しみと教育のための物で、派生的な仕事の基礎であってはならない。 付録 A.3 すべての配布に対する全般的な規則 以下の条件を満たすとき、ある種の非常に特定の条件の元に本パッケージの配布許諾は事前に許可される。 これらのアーカイブは、POV-チームの明示された許可なしで異なる方法を使って、再アーカイブされてはならない。あなたはあなたのシステムのファイル名規則に合わせるために、あるいはファイル名の重複をさけるためにだけアーカイブの名前の変更をしても良いが、われわれはできるだけオリジナルと類似した名前を保つように願う。 (例えば: povsrc.zip を povsrc30.zip ) また、それがハードディスク上に正しくインストールされたかのように、我々の標準のディレクトリあるいはフォルダー構造でファイルが配置されるならば、CD-ROMの上の実行準備ができたアン・アーカイブされた配布は許される。 次のセクションの中で記述されるように、あなたはファイルの完全なパッケージを配布しなければならない。以下に与えられた条項の中で指定された条件以外で、このパッケージの一部分がパッケージから切り離されてはならなくて、別々に配布されてはならない。 お金や代償の負担がない（個人の友人か同僚のためにソフトウェアをコピーしているユーザのような）無商用の配布は、他のいかなる制限もなしで許される。 ソフトウェアが授業において使われることになっているならば、教師と教育的施設は、また、学生に対して教材を配布してもよく、最小のコピーコストを負担させてもよい。 付録 A.4 「完全なパッケージ」の定義 POV-Rayは、各々ハードウェアプラットホームのためにアーカイブの2つのセットで含まれる。完全なパッケージは、いずれから成る： 1) 実行可能プログラム、ドキュメンテーションおよびサンプルシーンを含んでいるが、ソースは無いエンドユーザ用実行可能アーカイブ。あるいは 2）完全なソースコードを含んでいるプログラマ用アーカイブ、しかし実行可能でない。また、あなたはドキュメンテーションとサンプルシーンを含んでいるアーカイブを含めなければならない。いくつかのプラットホームの上で、ドキュメンテーションとサンプルシーンは、別々に元からアーカイブされている。ソースは、単独では十分でない。あなたはdocs、そして、シーンが不可欠である。 POV-Rayは、MS-DOS; Windows 32-bit; Linux for Intel x86 series; Apple Macintosh; Apple PowerPC; SunOS; および Amigaのために公式に配布される。他のシステムは将来追加されるかもしれない。 ディストリビューターはすべてのプラットホームをサポートする必要はない、しかし、各々あなたがサポートするプラットホームのためにあなたは完全なパッケージを配布しなければならない。例えばマッキントッシュだけのBBSではWindows版を配布する必要はない。 本ソフトウェアは以下の条項に指定された条件に従う場合のみ、他のソフトウェアパッケージとバンドルしても良い。 シェアウェアやフリーウェア配布会社が、フロッピーディスク、CD-ROM、テープに記録したバックアップ、光ディスク、ハードディスクかメモリーカードのような、しかしこれらに限定されない、メディアを使ったソフトウェアだけの編集物に含まれた本ソフトウェアを配布することもできる。本セクションは、収集したプログラムのディストリビューターに適用されるだけである。シェアウェア製品とともに本パッケージをバンドルすることを望んでいる誰でもが商用のバンドル規則を使わなければならない。本、雑誌か他の印刷物でメディアをバンドルすることもまた商用の規則を使うべきである。 あなたは我々にPOV-Rayを配布していることを通知しなければならず、どのようにあなたと連絡をとるか我々に情報を提供しサポート供給ができるようにしなければならない。 本ソフトウェアのコピーとそれを備えるためのメディアに対してディスクあたり5米ドル($5)までしか負担させることはできない。ディスクスペースはできるだけ一杯に使わなければならない。必要以上に多くのディスクにファイルを広げてはならない。 バックアップテープやCD-ROMのような高ボリュームメディアの上の配布はユーザの総費用が、データのメガバイトにつき$0.08米ドルを越えなければ許可される。例えば、600メガをもつCD-ROMは、48.00ドルを越えてはならない。 付録 A.5 インターネットを含むオンラインサービスとBBSのための条件 オンラインサービス、BBSとインターネットサイトは、このセクションの中の条件でPOV-Rayソフトウェアを配布することもできる。ユーザが遠隔地からPOV-Rayを走らせることを許すサイトは下記のセクションの中の別の条項を使わなければならない。 アーカイブは、サービス上ですべて簡単に利用可能でなければならず、類似したオンライン領域においてまとめられるべきである。 サイトが、ユーザの混乱を避け、我々のサポート努力を単純化あるいは最小にするためにPOV-Rayの以前のバージョンを取り除くことを強く要求する。 サイトは、このソフトウェアをダウンロードするために標準の使用料金を負担させてもよいだけである。このパッケージの割増金を請求されてはならない。つまりCompuServeやアメリカオンラインはそれらのユーザにこれらのアーカイブを利用可能にすることもできる。しかし、それらはダウンロードするために要求される時間の代金を通常の使用料金で請求することができるだけである。 付録 A.6 POV-Rayのオンラインあるいは遠隔実行 (Online or Remote Execution of POV-Ray) いくらかのインターネットサイトが、遠く離れたユーザが、インターネットサーバーの上で実際にPOV-Rayソフトウェアを走らせることができるようにセットアップされた。他の会社は、POV-Rayソフトウェアをワークステーションか高速のコンピュータの上で走らせるためにCPU時間を売る。そのようなPOV-Rayのソフトウェアの使用は、以下の条件で許可される。 そのようなサービスでは料金や負担はたとえあっても、接続時間、記憶あるいはプロセッサ使用だけでなければならない。他のソフトウェアの使用での課金を越えてPOV-Rayの使用に対して割増金の負担を査定してはいけない。ユーザーはPOV-Rayソフトウェアの使用ではなくコンピュータの使用に対して課金されていることをはっきり通知されなければならない。 ユーザーはPOV-Rayソフトウェアを使っていること、そのようなソフトウェアが無料であること、公式のPOV-Rayソフトウェアをどこで見つけることができるかを目立つように通知されなければならない。ユーザがPOV-Rayを動作させている事実をおおい隠す試みは、特に禁止される。 すべての通常の完全なパッケージ配布で利用可能なファイル、特にこのライセンスのコピー、そして、ダウンロードかオンラインに読める完全なドキュメンテーションが利用可能で、したがってオンライン実行可能なユーザは、完全なユーザパッケージの材料のすべてに、アクセスできなければならない。 POV-Rayソフトウェアがどんな形であれ修正されるならば、また、それは以下のカスタムバージョンのための条項に従わなければならない。 付録 A.7 カスタムバージョン配布のための条件 ユーザーは彼自身の個人的使用のためにそれに合ういかなる様式にでもソースコードを修正しコンパイルする特権を与えられている。あなたが、あなた自身の自宅で本ソフトウェアで何をするかはあなたの業務である(訳注:われわれの関知するところではない)。 ユーザーが本ソフトウェア、ドキュメントあるいはパッケージの他の部分を修正したバージョンの配布を望む場合、(後での参照のためにカスタムバージョンと呼ぶ)彼らは以下の条項に従わなければならない。これは、ドキュメンテーションの他の言語への翻訳あるいは他のフォーマットへの変換を含む。これらのライセンス条項は、POV-Rayの成長を促進して、同様にユーザと開発者にとっての困難を妨げるために制定された。どうかそれにかかわるカスタムバージョンを作成しているときはそれらに注意深く従って下さい。 POV-Rayの基本関数をすべて含む明らかなPOV-Rayのカスタムバージョンである場合を除きPOV-Rayソースコードの一部分を、他のものに取り入れられてはならない。 すべての同じ実行形式プログラム、ドキュメンテーション、修正されたファイルの記述は、POV-Rayの修正された非公式のバージョンとして、はっきりそれ自身を識別しなければならない。ユーザがPOV-Rayを実行している事実をおおい隠す試みあるいはそれが非公式バージョンであることを覆い隠す試みは特に禁止された。 あなたのカスタムバージョンを使うすべてのユーザのために、あなたはすべてのPOV-Rayサポートを提供しなければならない。ユーザがあなたのカスタムバージョンのサポートのためにあなたと連絡をとるための情報を提供しなければならない。POV-Rayチームは、あなたもしくはあなたのユーザにいかなる技術的なサポートも提供する義務はない。 ソースファイルoptout.hの中のDISTRIBUTION_MESSAGEマクロに連絡先の情報を含め、プログラムが明示的にこの情報を表示することを保証して下さい。公式のバージョンのためのすべての著作権通知とクレジット画面を表示しなさい。 カスタムバージョンはフリーウェアとしてだけ配布できる。あなたはあなたのすべての修正がPOV-Rayがすべてのソースコードを含み、フリーでPOV-Rayの修正部分が公的に利用可能であり、カスタムバージョンの新しい部分のすべてのソースコードをフリーに配布するようにしなければならない。この目的はユーザが彼ら自身でプログラムを再コンパイルして、さらに彼ら自身の修正でプログラムを改善することができるようにすることである。 あなたが、あなたが配布しているプログラムに、あなたがしたすべての修正に関するドキュメンテーションを提供しなければならない。どのように公式のPOV-Rayを得るかの明確で明らかな情報含めてください。 ユーザは拡張とバグフィックスをPOV-Rayチームへ送るのを奨励される、しかし、チームはこれらの拡張やフィックスを利用することを決して要求されない。チームに材料を送ることによって、貢献者は、彼がその材料を所有し、あるいはそれらの材料を配布する権利を主張する。とにかく、彼がチームに材料を使う権限を与えるようである。貢献者はまだ贈与された材料に権利を保持する。しかし贈与によって譲渡、変更できない使用法と配布権利をPOV-Rayチームに与える。チームは材料を使う必要はない。しかし、我々がそうしても、あなたはPOV-Rayに関連した権利を得ない。応用できるならば、チームは新しいコードの創造者としてあなたに名誉を与えるだろう。 付録 A.8 商用バンドルのための条件(Conditions for Commercial Bundling) 商用のソフトウェア（シェアウェアを含む）あるいは出版物でPOV-Rayをバンドルすることを望むベンダは最初に明示的な許可をPOV-Rayチームから得なければならない。これは雑誌、カバー-ディスク配布、本、新聞、印刷あるいは機械読み込み可能な形態のニュースレターのような、しかし限定されない、商用のソフトウェアあるいは出版物を含む。 POV-Rayチームは、そのような配布がケースバイケースの基準で許さかどうか決め、あるいはある種の適当な制限を負わせるかも知れない。最低限の合意が以下に与えられる。他の条件が賦課されるかも知れない。 * あなたの製品の購入者は彼らがPOV-Rayに支払わされていると信じさせられてはならない。箱の上、広告する際、あるいは、指示マニュアルのPOV-Rayバンドルの記載は、POV-Rayが無料のソフトウェアであって、いろいろな供給源から無料あるいは名ばかりの費用で得られることができるというdisclaimerがはっきり記されていなければならない。 * どのように公式のPOV-Rayを得るか明確で明らかな情報含むこと。 * あなたは、すべてのPOV-Rayサポートをあなたの製品を通してPOV-Rayを得たすべてのユーザに与えなければならない。POV-Ray開発チームは、あなたとあなたの顧客にいかなる技術的なサポートも提供する義務がない。 * あなたのドキュメンテーションの中でPOV-Rayのためにクレジットページを含みなさい。 * もし、あなたのハードウェアかソフトウェアで使うために部分的にPOV-Rayを修正するならば、あなたは、これらの規則に加えてカスタムバージョン規則に従わなければならない。 * あなたの製品に対する連絡とサポートの情報を含んで下さい。 * 先に述べたように完全なユーザパッケージを含みなさい。 付録 本ソフトウェアの小売値 POV-Rayは、本取り決めの条項の範囲内で配布する場合は無料であるが、本プログラムの配布あるいはコピー毎の小売値(あるいは価格)をUS $20.00と決めた。許可無く本ソフトウェアを配布あるいはコピーする場合、著作権保有者あるいは著作権保有者が派遣したこの負債に対する集金者に対して正当に負債を負う責任があり、上記に正当に拘束され、この負債をそれが生じた時点から30日以内に支払うことを合意する。 しかしながら、上項は、本合意外の本ソフトウェアの配布に関する許諾を制定するわけではない。特に上記で言及した条件と負債は(払われるか払われないかにかかわらず)、あなたが法令上の損害賠償あるいは他の正当な罰則を回避するのを許すわけではなく、またあなたが、著作権保持者が入手可能な他の正当な慰謝料を回避するのを許すなんらの取り決めを制定するわけではない。 簡単にいうと、あなたが我々の配布条件に応ずるならばPOV-Rayは無料である;それ以外は無料ではない。本ソフトウェアの著作権保持者はこれらの条件の下でのみ無料で手渡すことを選択する。 著作権規定の目的で、本ソフトウェアの小売値はコピーあたりUS $20.00である。 付録 A.10 他の条項(Other Provisions) チームは、POV-Rayシーン記述言語のファイルをインポートするか、イクスポートするか、変換する商用のパッケージを含むプログラムの作成を許して、奨励する。言語それ自身を使うことに対する制限はない。我々は言語の任意の部分を、付け加え、取り除き、変更する権利を留保する。 "POV-Ray", "Persistence of Vision", "POV-Ray Team" および "POV-Help" はPOV-Ray Teamの登録商標である。 我々は単独の文字「POV」の制限を主張しないけれども、あなたがあなたの製品の名にPOVを使わないことを謙虚に要求する。そのような利用法は、それがPOV-Rayチームの製品であることを意味する傾向がある。このドキュメントの出版以前に"POV"を使っているプログラムは、あなたがそのプログラムが本チームの仕事ではなくわれわれの記名がないことをわかりやすくしてくれれば、罪悪感を感じることはありません。 付録 A.11 ライセンスの取り消し(Revocation of License) VIOLATION OF THIS LICENSE IS A VIOLATION OF COPYRIGHT LAWS. IT WILL RESULT IN REVOCATION OF ALL DISTRIBUTION PRIVILEGES AND MAY RESULT IN CIVIL OR CRIMINAL PENALTY. (このライセンスの違反は著作権法違反である。その結果はすべての配布特権の取り消しと民事あるいは刑事上の罰則となる。) 配布をするのを禁じられるような違反者は、この文書の中で確認されるだろう。 この関連でイギリスのFuture Publishing社の雑誌"PC Format"は当時有効であったラインセンスに違反するPOV-Ray 1.0の不完全なバージョンの配布を行った。彼らは後に、POV-Rayチームの事前の許可なしで、その時点で有効であったライセンスに違反するPOV-Ray 2.2 の配布を試みた。また、他にもFuture Publishing社が我々の項目に違反した証拠がある。 その結果Future Publishing の所有する"PC Format"、および他のすべての雑誌、書籍およびCD-ROM出版は後の通知まで明白にPOV-Rayソフトウェアの配布をするのを禁じられている。 付録 A.12 拒否(Disclaimer) このソフトウェアはいかなる保証も誓約もないものとして提供される。作者たちはパッケージのすべてのバグを見つけ修正しようと試みたけれども、パッケージの使用あるいは誤使用によるいかなる種類の損害や損失に対しての責任を負わない。作者らは本パッケージのサービス、修正およびアップグレードの義務を負わない。 付録 A.13 技術的な援助(Technical Support) 我々は、あなたが我々のプログラムで楽しんでくれることを心から望みます。あなたがプログラムに関する問題をお持ちならば、チームはそれらについてお聞ききしたい。また、あなたがコメント、質問あるいは強化策をお持ちならば、CompuServe情報サービスの上でGO POVRAYフォ-ラムでPOV-Rayチームと連絡をとってください。また、インターネット上でhttp：//www.povray.orgかftp.povray.orgで我々をチェックしてください。USENETグループcomp.graphics.rendering.raytracingは、POV-Rayと関連したトピックに関する情報の大きい供給源である。 ライセンスの問い合わせは電子メールを通してして下さい。そして、限られた技術的な援助も電子メールで利用可能です。送り先は： Chris Young POV-Ray Team Coordinator CIS: 76702,1655 Internet 76702.1655@compuserve.com 以下の郵便のアドレスは公式のライセンスビジネスと電子メールが不可能な場合のためだけのものです。 我々は、通常の郵便を通して技術的な援助を与えません。電子メールだけです。我々は、あなたがモデムやオンラインアクセスの手だてを持っていなくても関知しません。我々はあなたにアップデートされたバージョンのディスクを郵送しないでしょう。お金を送らないで下さい。 Chris Young 3119 Cossell Drive Indianapolis, IN 46224 U.S.A. 他の作者の連絡先は、セクション「作者」の中で見つけらるかもしれません（また、「POV-Rayチームメンバーのために葉書」も見て下さい）。 付録 B 作者 以下は、かつてPOV-Rayチームで働いた、あるいは注目すべき貢献をしたすべての人々のアルファベット順のリストである。あなたが著者に連絡をとるか、感謝したいならば、「POV-Rayチームメンバーのための葉書」と「作者と連絡をとる」のセクションを読んで下さい。 Claire Amundsen (Tutorials for the POV-Ray User Guide) Steve Anger (POV-Ray 2.0/3.0 開発者) CIS: 70714,3113 Internet: sanger@hookup.net Randy Antler (IBM-PCディスプレイコードの拡張) John Baily (RLE Targa コード) Eric Barish (グラウンドフォグのコード) Dieter Bayer (POV-Ray 3.0の開発者で文書のコーディネーター) CIS: 100255,3074 Kendall Bennett (PMODEライブラリのサポート) Steve Bennett (GIFのサポート) Jeff Bowermaster (ベータテスト) David Buck (DKBTraceのオリジナル開発者) (POV-Ray 1.0 の開発者) Chris Cason (POV-Ray 2.0/3.0 開発者、POV-Help、Windowsへの移植) Internet (優先): Chris.Cason@oaks.com.au あるいは Chris.Cason@povray.org CIS: 100032,1644 Aaron Collins (DKBTrace 2.12共著者) (POV-Ray 1.0 開発者) Chris Dailey (POV-Ray 3.0 開発者) CIS: Steve Demlow (POV-Ray 3.0 開発者) CIS: Andreas Dilger (POV-Ray 3.0 開発者) Internet: adilger@enel.ucalgary.ca Http://www-mddsp.enel.ucalgary.ca/People/adilger/ Joris van Drunen Littel (Macのベータテスター) Alexander Enzmann (POV-Ray 1.0/2.0/3.0 開発者) CIS: 70323,2461 Internet: xander@mitre.com Dan Farmer (POV-Ray 1.0/2.0/3.0 開発者) CIS: 74431,1075 David Harr (Macのバルーンヘルプとパレットコード) Jimmy Hoeks (Windowsユーザーインターフェースのヘルプファイル) Terry Kanakis (カメラの固定(Camera fix)) Kari Juharvi Kivisalo (グラウンドフォグのコード) Adam Knight (Macのベーターテスター、Mac Appleガイドの開発者) CIS: Lutz Kretzschmar (IBM-PCディスプレイコード[SS24 トゥルーカラー],アンチエイリアシングコードの一部) CIS: 100023,2006 Charles Marslett (IBM-PC ディスプレイコード) Pascal Massimino (フラクタルのコード) Jim McElhiney (POV-Ray 3.0 開発者) CIS: Robert A. Mickelsen (POV-Ray 3.0 文書) CIS: Mike Miller (アーティスト、シーンファイル、stones.inc) CIS: 70353,100 Douglas Muir (バンプマップ、ハイトフィールド) Joel NewKirk (Amigaバージョン) CIS: 102627,1152 Jim Nitchals (Mac バージョン、シーンファイル) Paul Novak (テクスチャへの貢献) Dave Park (Amigaのサポート、AGA ビデオコード) David Payne (RLE Targa コード) Bill Pulver (Time コード、IBM-PC コンパイル) Anton Raves (ベータテスター、いくつかのMacのthingiesに関する援助) CIS: 100022,2603 Dan Richardson (文書) CIS: Tim Rowley (PPM および Windows-用の BMP イメージのサポート) Internet: trowley@geom.umn.edu Robert Schadewald (ベータテスター) CIS: Eduard Schwan (Mac バージョン、モザイクプレビュー、文書) CIS: 71513,2161 Robert Skinner (ノイズ関数) Erkki Sondergaard (シーンファイル) CIS: Zsolt Szalavari (Haloのコード) Internet: zsolt@cg.tuwien.ac.at Scott Taylor (Leopardおよびonionテクスチャ) Timothy Wegner (フラクタルオブジェクト、PNGのサポート) CIS: 71320,675 Internet: twegner@phoenix.net Drew Wells (POV-Ray 1.0 開発者、POV-Ray 1.0 チームコーディネーター) Chris Young (POV-Ray 1.0/2.0/3.0 開発者、POV-Ray 2.0/3.0チームコーディネーター) CIS: 76702,1655 付録 C 作者と連絡をとる POV-Teamは、電子メールを通してCompuserveのPOVRAYフォーラム（GO POVRAY）の上で結びついているボランティアプログラマ、デザイナー、アニメーターおよびアーティストの集まりである。POV-Teamの目標は多くの異なるコンピュータに移植可能なCで書かれた、無料で配布可能な高品質のレンダリングおよびアニメーションソフトウェアを創作することである。もしあなたがPOV-Rayに関する疑問を持ったら、どうかChris Youngに連絡をとって欲しい。Chris Young POV-Team Coordinator CIS: 76702,1655 Internet: 76702.1655@compuserve.com 我々は、あなたが、どのようにプログラムを使っていて、楽しんでいるか伝え聞くのが好きである。われわれはまた、あなたがPOV-Rayに関して持った問題を解き、良い意見をプログラムに取り入れるためにベストを尽くすだろう。 もしあなたが商業利用、配布あるいは特にやっかいな(sticky)ことに関する疑問を持ったときは、どうか開発チームのコーディネーターChris Youngに連絡して欲しい。さもなければ、あちこちにメールをまきなさい。我々すべては、あなたから伝え聞くのが好きである！ われわれのほとんどにとって、最高の連絡方法はCompuServeを通したe-mailである。アメリカオンラインとインターネットも現在はCompuServeにメールを送れるし、また、単にインターネットアドレスを使ってもらうだけで、我々が毎日我々のメールを読むCompuServeのアドレスにメールが届けられるだろう。 最初に尋ねずにe-mailで大きなファイルを我々に送らないで下さい。われわれは毎分CompuServeにお金を払っているので、大きなファイルは高くつくのです。あなたがファイルを送る前に、質問を送ってください。ありがとう！ 付録 D POV-Rayチームメンバーへの葉書 あなたが、個人的にPOV-Rayチームメンバーの何人かに感謝したいのなら、あなたが住んでいるところならどこからでも彼らに葉書を送ることができる。あちこちに漂う無効なアドレスを避けるために(我々の何人かが移動する場合に備えて）以下に(アルファベット順で)リストしたアドレスは示された日付までしか有効でない。 Dieter Bayer Taeublingstr. 26 91058 Erlangen Germany (1998年3月31日まで。) Chris Cason (Windows バージョン) PO Box 407 Williamstown Victoria 3016 Australia (1998年12月31日まで。) Joel NewKirk 255-9 Echelon Rd Voorhees, NJ, USA, 08043 ( --まで) Eduard Schwan (Macintosh バージョン) 1112 Oceanic Drive Encinitas, California, USA, 92024-4007 (1998年6月30日まで) また、あなたは、我々は電子メールに返事をするだけであり、我々は通常の郵便や電話によって尋ねられた問題には答えないということを知っていて下さい。あなたの質問はセクション「著者と連絡をとる」の触れた電子メールアドレスに送ってください。 付録 E 名誉(Credits) ユーザードキュメンテーションへの貢献をしたので以下の方に名誉を与える(アルファベット順): Charles Fusner (ブロブ、レイズおよびプリズムのチュートリアル) 付録 F 助言とヒント(Tips and Hints) 付録 F.1 シーンデザインの助言(Scene Design Tips) DOSプラットホーム上で利用できるPOV-Rayのシーンファイルを作成するたくさんの素敵なCADライクなモデラーがある。この文書の他のどこかで触れられたオンラインシステムはそれらを見つける最適の場所である。 POV-Rayのために何百もの特殊な目的のユーティリティが作成されている: データ変換プログラム、オブジェクト生成、シェルスタイル・ラウンチャーそしてその他である。それらのすべてをここでリストするのは不可能であるが、リストされたオンラインシステムはそれらのほとんどを保持しているだろう。ほとんどはPOV-Rayの精神を引継いだフリーウェアあるいは安価なシェアウェアである。 いくつかの非常に丹念なシーンはグラフ用紙上で製図されることにより設計された。レイトレーサー Mike Millerは自然の10進の換算を許す10分の1に格子を分割したグラフ用紙を推めている。 basicvue.povのコピーのような、ボイラー板(boilerplate:型どおりの)シーンファイルで始め、そしてそれを編集しよう。一般に、原点の近くの周囲にあなたのオブジェクトを置き、そしてカメラを負のz-方向、つまり原点を見るようにしなさい。当然あなたはこの規則を何度も破るだろうが、始めるときには物事をシンプルにしなさい。 基本的で、退屈だが頼りになる照明のために光源をカメラの位置のそばに置きなさい。オブジェクトは平坦に見えるだろうが、少くともあなたはそれらを見ることができるだろう。そこからそれをより良い位置までゆっくり動かすことができる。 付録 F.2 シーンデバッギングの助言(Scene Debugging Tips) あなたの絵のクイックバージョン(高速版)を見るためにはそれを非常に小さく表現しなさい。計算するピクセル数が少なくなり、レイトレーサーはより素早く終了することができる。-W 160 -H 100 はそれに適切なサイズである。 それが適当な場合に +Qの品質スイッチを使いなさい。 もし絵に高解像度で見る必要のある特定の領域がある場合(多分粒子の細かいwoodテクスチャ)、多分アンチエイリアシングをonで+SC, +EC, +SR および +ER スイッチをウィンドウを孤立させるために使いなさい。 あなたのイメージがたくさんの相互反射を含むならば、max_trace_levelを1か2のような低い値にセットしなさい。終了したときにそれを元に戻すのを忘れないで下さい! 不必要な照明をoffにして下さい。デバッグに必要ない拡張したlightキーワードをコメントにして下さい。もう一度、あなたが夜中にやめる前に最後のレンダリングを走らせるとき、それらを元に戻すのを忘れないで下さい! もしあなたが視覚的な調査では理解できないエラーに陥ったならば、あなたのファイルを括弧でくくり始める時である。あなたの大部分のシーンを無効にし、再レンダリングを試すためにブロックコメント文字 /*... */ を使いなさい。あなたがもはやエラーを得ないのならば、当然問題はだいたい無効にした領域の範囲内に存在する。このようにゆっくりとした系統的なテストが最終的にはバグを見つけることができるか、静かに正気でなくなるかの点に落ち着かせるだろう。多分両方であろう。 もしあなたが自分自身あるいはあるオブジェクトを失ってしまったようなら(初心者におけるありふれた経験)、しばしば手助けになる2、3の秘訣がある: 1) 遠くの視点からの視野を得るために、あなたのカメラを後方へ動かしなさい。これは非常に小さいオブジェクトでは距離により見にくくなるので手助けにならないかも知れないが、いざというときのために用意しておく(keep sleeve)には素晴らしい秘訣である。 2) もしオブジェクトが単に光から隠されている疑いがあるのならば、ambient値を1.0にしてみなさい。これはそれを自己照明するようにし、シーンにライトがなくてもそれを見ることができる。 3) オブジェクトをより大きな球やボックスのようなより分かり切った"代役"オブジェクトで置き換えてみなさい。すべて同じ変換がこの新しいオブジェクトに適用されているか確認し、それが同じ場所で終了するようにしなさい。 付録 F.3 アニメーションの助言(Animation Tips) ソリッドテクスチャを持つオブジェクトをアニメーションにするとき、そのテクスチャはオブジェクトとともに動かなければならない。つまり、オブジェクトそれ自身のようにテクスチャにも同じ回転(rotate)あるいは平行移動(translate)関数を適用する。以下の例のようにもし変換がテクスチャブロックの後ろにあると、これは現在自動的になされる。 shape {... pigment {... } scale <... > } は形状とピグメントテクスチャを同じ量で拡大縮小(scale)する。 shape {... scale <... > pigment {... } } は形状を拡大縮小(scale)するがピグメントはしない。浮動小数点数およびベクトルを含むほとんどのデータ型に対して定数が宣言できる。これらをインクルードファイルに書き込み、簡単にアニメーションのためのパラメータを分離し別々のファイルにすることができる。宣言された定数のいくつかの例は: #declare Y_Rotation = 5.0 * clock #declare ObjectRotation = <0, Y_Rotation, 0> #declare MySphere = sphere { <0, 0, 0>, 1.1234 } 他の例はサンプルシーンファイルを通してバラバラに見つけることができる。MS-DOSユーザのための手引き:.FLI/.FLCアニメーションを作成するために dta.exe (Dave's Targa Animator)を保有しなさい。aaplay.exe と play.exe はこのタイプのアニメーションの一般的なビューアーである。 アニメーションでカメラを動かしているとき(あるいはそのために静止イメージに置いた場合)直接原点の上にカメラを置くことを避けなさい。これは奇妙なエラーを引き起こすだろう。その代わりに、中心から離れてわずかに移動して、直接シーンの上に浮かぶのを避けなさい。 付録 F.4 テクスチャの助言(Texture Tips) Woodは年輪がz-軸に沿って整列した丸太のように設計されている。一般にこれらは(1単位のオブジェクトに対しては)1/10ぐらいの量に縮小すると最良に見えるだろう。動乱(turbulence)も小さめの値から始めて下さい(0.05あたりが開始時には良いでしょう)。marble(大理石)テクスチャは、非常にx-gradientに似たピグメントプリミティブを囲んで設計されている。動乱が加えられたとき、その効果は側面から見るか端面から見るかで見え方が異なる。y-軸上でそれを90度回転させて違いを見よう。すっかり黒いオブジェクトでは鏡面ハイライティングは得られない。代わりに非常に暗いグレイ、例えばGray10やGray15 (colors.in から)を試して下さい。 付録 F.5 ハイトフィールドの助言(Height Field Tips) POV-Ray自身を用いてハイトフィールドのためのイメージを作成してみよう: camera { location <0, 0, -2> } plane { z, 0 finish { ambient 1 } // 光源は必要ない。 pigment { bozo } // あるいは何でも。実験してみなさい。 } これらが他のイメージでハイトフィールドで使えるa.tgaファイルを作成するのに必要なもののすべてである! 付録 F.6 座標形を変える(Converting "Handedness") もしあなたが他のシステムからイメージをインポートすると、形状が逆向き(左と右が逆になる)になり、回転ではそれを修正できないのに気が付くかも知れない。 多くの場合、あなたがしなければならないすべては、カメラを左から右へフリップさせるためにカメラの右方向(right)ベクトルのその項を逆にすることである(右手座標系を使う)。いくつかのプログラムは座標系を異なるように変更するようであるが、y-およびz-ベクトルをPOV-Rayと同じように働かすために、あなたは他のカメラ変換を実験する必要があるかも知れない。 付録 G 頻繁に聞かれた質問(Frequently Asked Questions) これは頻繁に尋ねられた質問のコレクションであり、そしてそれらの答えはCompuserveのPOVRAYフォーラムとcomp.graphics.raytracingニュースグループにポストされたメッセージから直接採用したものである。 FAQのこのバージョンは、POV-RayのIBM PCバージョンのCompuServeユーザの方へ重く偏っている。できれば後の改訂版では、この偏重を取り除くのが望まれるが、しかし現在、最も大きい聴衆である。 付録 G.1 全般的な質問(General Questions) Q: いつ、POV-Ray 3.0が、リリースされるだろう? A: すでに利用可能である。 Q: いつ、ソースコードがリリースされるだろう? A: ソースコードも利用可能である。 付録 G.2 POV-Rayオプションの質問(POV-Ray Option Questions) Q: モザイクプレビューを最初にどのように設定すれば8*8から、4*4と2*2を通らずに直接最終レンダリングまでゆけるだろう? A: +SP n あるいは Preview_Start_Size オプションを開始解像度を設定するために使いなさい。そして+EP n あるいは Preview_End_Size オプションを終了解像度を設定するために使いなさい。+SP 8 および +EP 8 により、8*8から始め8*8までゆく(1パスだけ)すると直ちに最終パスの1*1にゆく。 Q: 非常に小さいシーン、すなわち少ない数のオブジェクトで +MB スイッチを使うべきでしょうか。 A: それはオブジェクトの数とタイプに依存します。通常、常にバウンディングボックス階層を使っても( +MB 0)痛みはありません。もし1つか2つのオブジェクトしかないのなら自動バウンディングは使わない方がいいでしょう。 Q: +MB スイッチはイメージの品質に影響するの? A: いいえ。交差テストのスピードに影響するだけです。 Q: エラーメッセージが出たときにoptionsスクリーンがスクロールして見えなくなるのをどうやって避けるの? A: +P スイッチを使いなさい。POV-Rayが中断されたときやトレーシングが終わったときはいつでもoptionsのテキストをカーソルキーでスクロールバックさせることができます。 付録 G.3 インクルードファイルの質問 Q: ファイルtextures.v2の中で、glassテクスチャがコメントにされているけど。なぜ? A: 旧いglassテクスチャはglass.incに重複されています。旧いテクスチャ名は新しいネーミング構成に合わないのです。Glassは現在はT_Glass1、Glass2は今はT_Glass2にそしてGlass3は現在はT_Glass3です。旧い名前をコメントでなくすることは簡単にできますが、新しいネーミング構成を用いることを強く奨励します。 付録 G.4 オブジェクトの質問 付録 G.4.1 ハイトフィールドの質問 Q: コンピューターに8メガしかRAMが無いんですけど、1024x768のpotファイルとハイトフィールドとして同じ解像度のファイル(2つの別のシーン)を試そうとするとメモリー不足になります。メモリーが少ないためでしょうかそれともこの解像度はばかげているのでしょうか? A: スムーズなハイトフィールドはスムーズでないものに比べてたくさんのメモリーを消費します(だいたい3倍ぐらいたくさん)。実際はその解像度ならスムーズ化は必要ないので、スムーズにしないで下さい(もしスムーズ化をしているのであれば)。 Q:イメージマップとハイトフィールドで同じ画像(高さとカラーの意味がある関係を与える)を使いたいのですが。それはgifかbmpフォーマットを使っているときしかうまく働かないのでしょうか。potファイルがマップにならなかったのです(フォーマットがサポートされていない)。 A: potファイルはイメージマップとしてはサポートされていません。それらのPOV-Rayでの目的はハイトフィールドとしてのものです。それはあなたが16ビットのpotファイルのために使う連続的な可能性のあるカラーリングを使うfractintで目的にかなうgifファイルを作り、それをイメージマップとして使用するのを妨げない。イメージマップとハイトフィールドはイメージの左下が原点に位置する1*1(*1)の領域に初期化されることを忘れないで下さい。ハイトフィールドはx-z平面にあるけれども、イメージマップは、x-y平面で始められる。したがってあなたはイメージマップを整列させるためにイメージマップを(rotate x*90を使い)90度x-軸まわりに回転させなければならない 付録 G.4.2 テキストの質問 Q: フォントオブジェクトのサイズが分かる可能性がありますか? A: 残念ですがありません。 実際にそれは必要なんですが、それをするのは簡単ではありません。ベータリリースの何日か前まで、水平方向のスペーシングがずっとうまく働かなかった。現在それを修正したので、多分その長さを求める方法を想像することができます。 付録 G.5 大気に関する質問 付録 G.5.1 大気の質問(Atmosphere Questions) Q:なぜ、私が付け加えた大気が、見えないの? A: シーンに大気を加えたときに作られる最もありふれたエラーは、カメラが現在入っているすべてのオブジェクトにhollowキーワードを付けていないことである。部屋をモデル化するために使われるボックスの中にあなたが居る場合、hollowキーワードをbox構文に加えなければならない。もし、平面(plane)が地面をモデル化するために使われるのなら、あなたはそれをhollowにしなければならない(あなたが平面の内側にいる場合だけであるがいつでもそれができることを確認して欲しい)。これが役に立たないならば、あなたが検査しなければならない他の問題があるかもしれない。大気の距離(distance)と散乱(scattering)値はゼロより大きくなければならない。大気に影響し合う光源はatmosphere off 構文を含んではならない。 Q:なぜ、私の半透明のオブジェクトを通して大気がいずれも見えないの? A: もしあなたが半透明なオブジェクトを持つ場合は(ほとんど)常にそれにhollowキーワードを加えて中空(hollow)にしなければならない。交差が見つかり光線が中実オブジェクトの内部にある場合はいつでも大気の効果は計算されない。 例えばもしあなたが部分的に透明な平面を持つとして、その平面の反対側の大気はもしその平面が中空(hollow)の場合のみその平面を通して見ることができる。 Q: なぜ大気の照らされた部分が背景を増幅するの? A: 第一に、そんなことはない。 第二に、大気を通して背景の一部が見える場合、および大気のそれらの領域が光源で照らされるときはいつでも、散乱される光は背景から来る光に加えられる。これが背景が大気により増幅されるように見える理由である。以下の例を想像してみなさい:あなたが観察者に届くカラーが<0,0,0.2>になるように大気により減衰させられる青い背景を持つ。光源から来たある光が大気で減衰され散乱され、最終的に観察者に届くカラーが<0.5,0.5,0.5>とする。すでに背景から来る光があるので、両方の光が加えられ<0.5,0.5,0.7>になる。このように光は青い色相を得る。結果としてあなたは背景の光が増幅されたと思うが以下のシーンがはっきりと示すようにそうではない。 #version 3.0 camera { location <0, 6, -20> look_at <0, 6, 0> angle 48 } atmosphere { type 1 samples 10 distance 20 scattering 0.3 aa_level 3 aa_threshold 0.1 jitter 0.2 } light_source { <0, 15, 0> color red.7 green.7 blue.7 shadowless } light_source { <-5, 15, 0> color rgb <1, 0, 0> spotlight point_at <-5, 0, 0> radius 10 falloff 15 tightness 1 atmospheric_attenuation on } light_source { <0, 15, 0> color rgb <0, 1, 0> spotlight point_at <0, 0, 0> radius 10 falloff 15 tightness 1 atmospheric_attenuation on } light_source { <5, 15, 0> color rgb <0, 0, 1> spotlight point_at <5, 0, 0> radius 10 falloff 15 tightness 1 atmospheric_attenuation on } plane { z, 10 pigment { checker color rgb<1, 0, 0> color rgb<0, 1, 0> } hollow } 図()　大気は背景に見えるものを増幅するようだ。 背景であなたは赤/緑の格子縞模様の平面を見る。大気を通して見える背景の色はスポットライトから散乱する光に加えられる。あなたは赤いスポットライト円錐の後ろの赤い正方形は円錐の外側のものよりも明るいけれど緑のものはそうではないことに気が付くだろう。緑のスポットライトに対しては状況が逆さになる:緑の正方形は増幅されたようであるが赤はそうでない。青いスポットライトはこの効果をまったく見せない。 Q: ドキュメントでは大気(atmosphere)のdistanceパラメータはフォグ(fog)のdistanceと同じように働くというけど、それは正しいの? A: はい、正しいです。大気の代わりにフォグを使ってみなさい。もしすべてが良く見えたら、つまりまだ背景あるいはあなたが見たいものが何でも見ることができたら、大気に対して同じdistanceとカラー(color)を使いなさい。 付録 G.5.2 フォグの質問 Q: わたしはグラウンドフォグを含むシーンを作るのにmorayを使っている。問題はフォグがy-軸に沿ってフェイドアウトすることです。morayではz-axis軸が上なので、フォグ層ではなく壁ができます。どうしたらいいでしょう? A: グラウンドフォグが使われている上方向を指定するために使えるupキーワードがあります。あなたのfogにup zの行を加えることが手助けになるでしょう。 付録 H お勧めの読み物 「POV-Rayに関する書籍およびCD-ROM」の中で触れたPOV-Rayに関する本の他に、あなたが、あなたの地区のコンピュータ関係の書店やあなたの地区の大学図書館で見つけることができるいくつかの良い書籍あるいは定期刊行物がある。 (訳注:書名のみ参考のため「」に訳した。邦訳版があったとしてもその題名とは関係ない) "An Introduction to Ray tracing" 「レイトレーシング入門」 Andrew S. Glassner (editor) ISBN 0-12-286160-4 Academic Press 1989 "3D Artist" Newsletter "The Only Newsletter about Affordable PC 3D Tools and Techniques") 「入手可能なPC 3Dツールと技術に関するニュースレター」 Publisher: Bill Allen P.O. Box 4787 Santa Fe, NM 87502-4787 (505) 982-3532 "Image Synthesis: Theory and Practice" 「イメージ総合：理論と実際」 Nadia Magnenat-Thalman and Daniel Thalmann Springer-Verlag 1987 "The RenderMan Companion" 「RenderManの仲間」 Steve Upstill Addison Wesley 1989 "Graphics Gems" 「グラフィックスGem」 Andrew S. Glassner (editor) Academic Press 1990 "Fundamentals of Interactive Computer Graphics" 「対話的なコンピュータグラフィックスの基礎」 J. D. Foley and A. Van Dam ISBN 0-201-14468-9 Addison-Wesley 1983 "Computer Graphics: Principles and Practice (2nd Ed.)" 「コンピュータグラフィックス：理論と実際(第二版)」 J. D. Foley, A. van Dam, J. F. Hughes ISBN 0-201-12110-7 Addison-Wesley, 1990 "Computers, Pattern, Chaos, and Beauty" 「コンピュータ、パターン、カオスと美しさ」 Clifford Pickover St. Martin's Press "SIGGRAPH Conference Proceedings" 「SIGGRAPH会議議事録」 Association for Computing Machinery Special Interest Group on Computer Graphics "IEEE Computer Graphics and Applications" 「IEEEコンピュータグラフィックスとアプリケーション」 The Computer Society 10662, Los Vaqueros Circle Los Alamitos, CA 90720 "The CRC Handbook of Mathematical Curves and Surfaces" 「数学的カーブと表面のCRCハンドブック」 David von Seggern CRC Press 1990 "The CRC Handbook of Standard Mathematical Tables" 「標準の数学的表のCRCハンドブック」 CRC Press The Beginning of Time 付録 I ヘルプに関するヘルプ(Help on Help) ヘルプリーダーを用いる (POVHELP.EXE) 知られている不和合性(KNOWN INCOMPATIBILITIES) クイックイントロの後を見なさい。 クイックイントロ ヘルプリーダーをポップアッププログラムにするために +E オプションを使いなさい。次のセクションに行くためにスペースを使いなさい。セクション間を移動するためにまた Ctrl-PgUp と Ctrl-PgDn を使いなさい。ハイパーテキストリンクをハイライトするためにTabを使いなさい。コードフラグメントをハイライトするためにAlt-Tabを使いなさい。ハイライトにしたハイパーテキストリンクにジャンプするためにEnterを使いなさい。一度リンクジャンプを開始したら関連したセクションにジャンプするために+/-を使いなさい。サーチ/ジャンプの前の場所に戻るために BACKSPACE を使いなさい。キーワードを検索するために 'S' を使いなさい。セクションを読んでいる時、テキストのジャスティフィケーション(右揃え)をトグルするために 'J' を使いなさい。キーボードバッファを通してあなたのアプリケーションにコードをペーストするために 'P' を使いなさい。 POV-Helpは80桁を変えるために用いられる何かのプログラムによってBIOSコラムカウントが正しく更新されることにより非標準のページ幅を扱うだろう。 あなたがPOV-Helpをポップアッププログラムとして使う場合、ポップアップするときのカーソルの下の単語を検索しようとするだろう。注意:あなたがホットキー(デフォルトはALT-ESC)を使ってポップアップモードを抜けるとき、POV-Helpはこれをあなたが次回、同じ場所に戻りたく、検索を実行しないことを意味するものと受け取る。検索はあなたが(あなたが現在の題目を終えたことを意味する)ESCAPEを使って抜けたときのみ実行される。 バックスペースを用いることによって始動させられたヒストリスタックは、32のエントリを保つ。 知られている不和合性(KNOWN INCOMPATIBILITIES) POV-HelpはMS-DOSのEDITプログラムでは動作しない。[事実、EDIT.COMは実際はいくつかのアドオン付きのQBASIC.EXEである ; EDIT は走るのに QBASIC を必要とする。] あなたのエディタで動作しない場合は、これを試しなさい(マクロ機能があるものと仮定する - o カーソル下の単語を得るマクロを書きなさい o その単語をパラメータとして POVHELP.EXE を呼びなさい o このマクロを選択のキーシーケンスにバインドしなさい コマンドライン (大文字小文字の区別はない) +Iname 別のファイルnameを使う (デフォルトは HELP.PHE) +N123 123番目のセクションへ行く(セクション123ではない!) +S4.5.6 セクション'4.5.6'へ行く +Tsphere または "+Tsphere" タイトルに'sphere'が見つかる最初のセクションへ行く。 +W50 ウィンドウ幅 40 文字 (最大 127) +H15 ウィンドウ高さ 15 行 (最大 21) +J[-] 行揃え ON (デフォルト)、 -J- offに切り替え +PH[n] ペーストの際、各CRの後'n'個HOMEキーを送る。デフォルトは-ph1。 +KALT-ESC ホットキーシーケンス。CTRL|ALT|CTRL-ALT+[任意 文字]|[ESC]でも良い。例えば +KCTRL-ALT-P、+KCTRL-1、 +KALT-CTL-'。CTL もまた受け入れられる。 +Eabc d e プログラム 'abc' をパラメータ 'd' と 'e'で起動する。 '+e'の後ろのパラメータはプログラムに渡される。 text +E parameter(パラメータ)をとらないことを除き +T と同じ。 ビューアコマンド トップメニュー Up, Down ハイライトバーの移動 Enter 選択した項目を見る Escape ヘルプビューアを抜ける 作者、著作権 Up, Down スクリーンのスクロール PgUp, PgDn スクリーンのスクロール Left, Right スクリーンのスクロール Escape トップメニューに戻る セクション Up, Down スクリーンのスクロール PgUp, PgDn スクリーンのスクロール Left, Right スクリーンのスクロール Escape トップメニューに戻る Space か CtrlPgDn 次のセクションを見る CtrlPgUp 前のセクションを見る "+", Enter 最初/次の ハイパーテキストリンクにジャンプ "-" 以前の リンク/オリジナル セクションへジャンプ "B" オリジナルセクションへジャンプして戻る(リンクジャンプ前から) Tab 次の見えるリンクを選択、, 最後から最初へ制御する ShiftTab 直前の見えるハイパーテキストリンクの選択 AltTab ペーストのためのコードフラグメントの選択 "P" キーボードバッファを通してハイライトされたコードフラグメントをペーストする 一般 ヘルプリーダーはほとんどのテキストをラップする。指定された部分、リスト、および僅かな他のものは除外される。必要であればそれらをスクロールするために左右の矢印キーを使いなさい。 ヘルプリーダーはエディタプログラムまわりの'shell'を意味する。人によっては用語'shim'(くさび)をむしろ好む。 大部分のメモリ必要条件のためにEMSを用いて、それは自分自身をロードし、ポップアップヘルプ機能を与える。またシーンの中にコードフラグメントをぷーすとすることも可能である。もしあなたのエディタが、例えば、'ME'ならば、あなたのシーン開発ディレクトリに'ME.BAT'と呼ばれるバッチファイルを置くだろう。あなたが'VI'を使うのならば、'VI.BAT'、そしてその他を作成するだろう。 (あなたのエディタ名.BAT) 望むキーシーケンス ---- | ----------- -------------- ---------------- povhelp |+W50 +H15| |+KCTRL-ALT-H| |+Ed:\me\me.exe| %1 %2 %3 %4 %5 ----------- -------------- ---------------- | | ウィンドウのサイズ | | エディタのパスで置き換えなる------------ 例えば - povhelp +W50 +H15 +KALT-H +Ed:\me\me.exe %1 %2 %3 %4 %5 このコマンドラインは、50x15ウィンドウで、エディタ'd:\me\me.exe'からALT-HキーシーケンスでポップアップするバージョンのPOV-Helpを与えるだろう。もしキーシーケンスを与えないと、POV-HelpはデフォルトのALT-ESCを使う。 これはヘルプリーダーをロードし、それから ME.EXEをロードし、ことを正常に続ける。あなたがエディタを抜けると、ヘルプリーダーは自動的にアンロードされる。POVHELPをポップアップするためにALT-ESCキーシーケンスを使うことができる。これはデフォルトである ; それを設定する方法がある。+E パラメータの後ろには何のパラメータも現れないだろう。それらは動作しているプログラムに渡されるだけである。 ポップアップのためにホットキーを使うと、POVHELPはカーソルの下の単語に基づいてセクションとタイトルのsimplisticな検索を行う。もし見つかれば、それを得る。そうでなければあなたがホットキーで抜け出なければメインメニューになる。 あなたが実際のセクションテキストからホットキーで抜けることができ、同じホットキーで入ることができる。あなたがescapeを押すと、トップメニューに戻る。しかしあなたがホットキーで抜けると、あなたのプログラムに戻る。次の時あなたがホットキーを押すと、同じ場所に戻る。この場合検索は行われない。 POVHELP はシェルプログラムとして実行されている場合 EMS を必要とする。 あなたが +E パラメータを指定しなければ、POVHELPはスタンドアロンプログラムになる。その場合EMSを使わない。 Alt-Tabを用いてコードのセクションをハイライトにして、POV-Helpをポップアップモードで使用している場合、'P'を用いてそのコードをキーボードバッファを通してペーストできる。 今日、多くのエディタがアートインデントを使う。これはコラム調整において問題を引き起こすかも知れない。その理由のため、POV-Helpはデフォルトで各CRの後にHOMEキーコードをキーボードバッファに挿入する。いくつかのエディタは左コラムを得るために、1つより多くのHOMEキー操作を要求する。この理由のために、+PH[n]コマンドラインパラメータを用いて送るHOMEの数は0(なし)から9までに調整する事ができる。'n' は任意の0から9までの値でデフォルトは1である。 POV-Help は Christopher J. Casonにより作成された。 CIS : 104706,3166 Internet : povray@mail.oaks.com.au Chris.Cason@povray.org POV-HelpデータベースをPostscript、LaTeX、RTF、Windows Help、HTML、その他のような他のフォーマットに変換するコンバータは利用可能である。 POV-Helpデータベースのフォーマットは文書化されていて無料で利用できる。 POV-Helpは、無料である。売られてはならない。詳細はPOVLEGAL.DOCを見なさい。POV-Helpプログラムの一式の著作権は copyright (c) 1994 C.J. Cason and the POV-Team.