USB 3.1
USB 3.1 Type-Cについて触れられています。
Type-Cコネクタはリバーシブル仕様で比較的コンパクトなことから、Lightningコネクタと比較されることが多く、かつ、USB 3.1が10Gbps対応や最大100Wの供給電力があることから、Thunderboltピンチみたいな話になりがちですが、実際のそれぞれのコネクタを並べて比較を行っている記事が上のリンクっすね。
ここで注目したいのは
なお、ケーブル長が1mを超えると転送速度理論値は5Gbpsとなり、USB PD(Power-Delivery)非対応ケーブルの場合、最大5V/1.5Aまたは5V/3A出力までの利用となります。という部分。その下のくだりで触れられていますけど、Thunderbolt 2の速度とケーブル長を考えると、とりあえずUSB 3.1でそれを置き換えることは出来なさそうです。
とはいえ、一般のUSB端子は全部このリバーシブル仕様というType-Cに置き換われとは思ったりはしますな。今日もUSBメモリをポートに差し込む時、差し込もうとしてささらないから裏返してそれでもささらずにまた裏返して…って事を繰り返したし…。Lightningはその辺、じつに素晴らしいと思います。
速度面でUSB 3.1が10Gbpsという数字は、実行速度は最適化したシステムで1.0GBpsになるようです。USB 3.0は400MBpsって事なので、大幅に高速化するし、もしかしたら、現在販売されているThunderbolt接続のRAID HDDの多くはUSB 3.1でもまかなえちゃうのかもしれませんね。超高速なSSDデバイスについてはちょっと足りないかもしれませんけど。
まぁしかしUSB 3.1からDisplayportへの変換も可能みたいですし、多くの場合、USB 3.1で十分ってことになるんだろうなぁって気はしてきました。
ちなみに、ディスプレイへの接続ということを考えた時、対象が4K以上の解像度となった場合、USB 3.1ではやはり役者不足と言っていいでしょう。4K30p出力は可能のようですが、普段使いするなら60pはやっぱり欲しいですからね。で、5KをターゲットにしたのがDisplayport 1.3なわけですが、その帯域に対応するThunderboltの規格が次世代のAlpine Ridgeという名前で噂されている物ですね。去年の4月にIntelの資料がリークされたってことで話題にあがって来たものですけど、その後続報は特にないのかな。だから、その時の情報を参考にすると40GbpsとなりPCI Express 3.0対応となり、100Wまでの電源供給が可能とか言われているみたいです。コネクタ形状もちょっと変わるらしい。
こいつとUSB 3.1が搭載されたMac ProやMacBook Proが早々に登場することを期待しております。
梅観てきた
まぁやっぱり咲きはじめなんですけどね。開花状況は紅いのが五分、白いのは咲きはじめだそうです。
この樹が全部色づいてたら綺麗だよねぇと想像しつつ歩いたり。
斜面の比較的狭い範囲に植えられているのだけど、何せけっこうな斜面だから必然的にゆっくりと観ていくことになります。
しかし今日は本当に暖かかった。梅まつり会場は標高250m付近って事なんだけど、筑波山山頂でも11度ぐらいはあったようです(会場との標高差は600m程なのでざっくり山頂より3.6度程気温が高い、つまり15度以上の気温があったと想像)。軽めのダウンを着ていたのだけど、それは必要ありませんでした。まして斜面を登るのだから暑くなっちゃうわけで。
気温が上がったののと同時にありがたかったのは日が差してくれたこと。会場にいた前後は曇っていたのだけど、会場にいた時だけ、日が差してくれたのはラッキーでした。天気が回復してくるようなら、ケーブルカーに乗って山頂目指しても良かったのだけど(さすがに歩いて登る気にはならないだろうけど)、前述の通り天気は再び悪くなっていく方向だったのでやめめました。
ついでに書くと、この山にいる間、花粉症の症状をほとんど感じることはなかったのだけど、地元に近づくにつれどんどん目がかゆくなってきたのはなんなんだろうなぁ。…と思って花粉飛散状況のサイトはなこさんを見てみると、まぁ納得です。筑波山あたりは花粉はあんま飛んでいなかったってことっすなぁ。
ペンタックスの新製品
上位機並みの性能を備えた世界最小の防塵・防滴デジタル一眼レフカメラ「PENTAX K-S2」を新発売 [リコー]
Kマウントデジタル一眼カメラ用交換レンズ「HD PENTAX-DA 18-50mmF4-5.6 DC WR RE」新発売 [リコー]
Kマウントデジタル一眼カメラ用高性能スターレンズ「HD PENTAX-D FA★ 70-200mmF2.8ED DC AW」新発売 [リコー]
Kマウントデジタル一眼カメラ用交換レンズ「HD PENTAX-D FA 150-450mmF4.5-5.6ED DC AW」新発売 [リコー]
一番上は一眼レフのデジカメで、けっこう斬新な印象のK-S1の上位機に位置づけられるものだそうです。防塵・防滴のボディを採用していて、K-3危うしという気分に若干なりますが、各機能の性能はそれぞれ一段下と言っていい数値のものが採用されておりますな。それでもローパスセレクターを採用してきたり、K-3にはないバリアングル液晶モニターを採用したり、Wi-Fi対応してたりとなかなか良い内容を持ちつつ、それなりにリーズナブルな価格で提供されるんだから、良いんじゃないでしょうか。
とはいえ、キットレンズは
smc PENTAX-DA L 18-50mm F4-5.6 DC WR RE
smc PENTAX-DA L 18-50mm F4-5.6 DC WR REとsmc PENTAX-DA L 50-200mm F4-5.6 ED WRのセット
smc PENTAX-DA 18-135mm F3.5-5.6 ED AL[IF] DC WR
の三種類で、一緒に正式された新レンズHD PENTAX-DA 18-50mmF4-5.6 DC WR REでは無いようです。
この新レンズは特徴としてはコンパクトというのがあるようですね。収納時の厚みは41mmだそうです。K-S2のキットレンズはHDのとベースは同じだけど、マウント部の素材やコーティングが違うのかな? その辺が廉価版の造りになったいるようです。
ちなみに、近いスペックのLimitedレンズであるHD PENTAX-DA 20-40mmF2.8-4ED Limited DC WRの厚みは68.5mmでございます。2cm以上薄いってのはちょっと魅力的に見えてきましたよ?
でもって、望遠ズームと超望遠ズームレンズの二種ですね。しかもDAじゃなくてFAレンズです。
HD PENTAX-D FA★ 70-200mmF2.8ED DC AW
HD PENTAX-D FA 150-450mmF4.5-5.6ED DC AW
いずれもメーカー希望小売価格が30万円を超えるものなので、そうそう手を出せるものではありませんが、これらは手に入れるのが夢っすなぁ…。
コンパクトデジカメではRICOH WG-5 GPS [リコー]が一緒に発表されています。水深14mで水中撮影が可能なものとのこと。
以上はもう来月ぐらい(望遠レンズの方はもうちょっと先?)には手に入れられる商品という事になりますが、今後登場するものもいくつか姿が見えてきました。その最たるものがフルサイズ機の開発を発表したってので、それがあるからこそのFAレンズの新製品なのでしょうな。
リコーイメージングがフルサイズ一眼レフの開発を発表 [デジカメinfo]
コンパクトなもので、K-3の後継って雰囲気で登場したら、次のやつの候補に上がってくるかもしれないなぁ、って思っております。
Kマントレンズのロードマップ(PDF注意)が更新されて、超広角から100mmぐらいまでのレンズ4本が予定されている事がそこから分かります。しかもそのうち3本がFAレンズということで、フルサイズ一眼のリリースに間に合わせる感じなんでしょうかね?
Q周りは特に発表がなかったのはちょっと淋しいっすね。次のレンズ、何が来ましょうか(一応、TELEPHOTO MACROって部類のものがプランニングされているようですが…)。
そんなわけで、少しだけにぎやかだったペンタックス界隈の話題で、ちょっとだけ楽しかった昨今です。
Autodeskの新プラン
従来からのユーザでメンテナンスサブスクリプションに入っている場合は引き続きそのサービスが提供されるとのこと。
例えばMayaならダイキンだと
1年分のベーシックサポート:204000円
3ヶ月分のベーシックサポート:64000円
となっていますね。現状では、永久ライセンス プラス メンテナンスサブスクリプションの組み合わせで入手することも可能みたいで、この場合、新規の価格が(フローティングライセンスで)640000円にサブスクリプションを98000円という事になります。
Autodeskのリリースには
オートデスク株式会社は、2016 年 2 月 1 日以降に販売する単体ソフトウェア製品を「Desktop Subscription」(デスクトップ・サブスクリプション)でのみ提供します。としているから、来年の2月からは永久ライセンスを購入できないってことなのでしょう。
デスクトップサブスクリプションによる更新とメンテナンスサブスクリプションによる更新は、だから6年目ぐらいまではまだデスクトップサブスクリプションで購入したほうがお安いのだけど、7年目以降はデスクトップサブスクリプションの方がお高くなるという勘定になりますが、将来にわたって値段が維持される保証もないし、将来、メンテナンスサブスクリプションの人も、あるバージョン以降を使おうと思ったらデスクトップサブスクリプションに移行なんて事もありうると思うので、あんまり意味のあるシミュレーションじゃないですね。ていうか、近い将来、メンテナンスサブスクリプションもなくなるんじゃないかなぁって思っていますです、正直。まぁでも現状のFAQ(PDF注意)を見ると
お客様は永久ライセンスを Desktop Subscription に変更することはできますか?ってなってるし、やるとしてもまだまだ先かな(と油断してたら一気に進行したのがAdobeっすな)。
いいえ、できません。
個人的には、ちょっと本気で個人利用のAutodeskライセンスは切ろうかなぁって考え出しております。今年の更新はやらないかもですよ。
(タイミング的に、今年の更新をせずとも2016バージョンの利用権は保持できるし。それで2年ぐらいはもつんじゃないかな?)
で、裏でHoudiniを触りたい…
これは期待できるかな?
現在ベータリリースみたいですね。
もともと、Affinity Designerってツールがでてて、高機能であるために、個人的にはこれで日本語の扱いに問題がないようなら(ドローツールとして日本語入力に問題がないのなら)、プリンタからの出力に問題がないのなら、是非とも試してみたいと思っていた、どちらかというとIllustratorの代替ツールととらえていたものなんですけど、そこの会社から、新たなツールがリリースされるようです。
軽快なデモムービーになっているせいか、とてもよさげに見えますね。
期待したいです。
ちなみに、Affinity DesignerのFeature Overviewなビデオは以下。
Finderのコピー速度
Yosemite 10.10.2 のFinderからNFSでマウントしたLinuxによるファイルサーバー(ちゃんとした性能を持った物のはず)へ、4000ファイル14232.84375MBのファイルコピーに要する時間。Finderでコピー元、コピー先両方開いておいて、コピーするファイル達をコピー先にドロップした時にストップウォッチをオンです。オフにするタイミングは、Finderでコピーが終わった通知音が鳴った時にしております。接続はギガビットのイーサーネット。ファイルは一個3MB弱となっております(exrファイルです)。
MacBook Pro→サーバー:6m51s(約35MB/s)
サーバー→MacBook Pro:3m35s(約66MB/s)
ちなみに、Blackmagic Disk Speed Testで速度を測るとRead/Write共に110MB/s程出ますんで、割とちゃんと性能が出ているように見えますね。
試しにターミナルからcpコマンドでコピーしてみました。こちら[トミリュウ・コム]を参考に、以下のシェルスクリプトを走らせます。
#!/bin/sh echo `date '+%y/%m/%d %H:%M:%S'` cp [コピー元ディレクトリ]/*.exr [コピー先ディレクトリ] echo `date '+%y/%m/%d %H:%M:%S'`
MacBook Pro→サーバー:2m49s(約84MB/s)
サーバー→MacBook Pro:2m39s(約89MB/s)
ん?速度が全然違う。Finderのコピーが遅いってのは本当なんだなぁと実感しました。
なんかいいツール無いかなぁとネットをあさっていたら、"RapidCopy" MacOSX用高速ファイルコピーソフト [L'espace Vision Co.,ltd] ってのが開発中ってのを知りました。ポスプロ屋さんが開発をしているってことすかね。大量の連番ファイルとか扱いそうなところだし、現在クローズドベータらしいけど、期待できそうです。
確実なコピーということではバックアップ系のソフトがありまして、例えばBackupList+なんてフリーで使えて有名かもしれません。こいつでMacBook Proからサーバーにファイルを送ってみましたが、3m6sで終わりました。Finderよりよほど高速です。
こうしてみると、大量のファイルを送る場合、Finderを使うってのはあまりいい選択肢じゃないかもしれないと思えてきますね。
そうなると、Path Finder 7 [Cocoatech] とか選択肢に上がってくるかもです。体験版を入れてみました。
MacBook Pro→サーバー:3m11s(約74MB/s)
サーバー→MacBook Pro:2m39s(約89MB/s)
ふむ。Finderより圧倒的に高速ですし、もしかしたら信頼性もありそうです(この辺は過去のFinderの実績からくる単なる印象ですけど)。
こうなると、Finderを置き換えたくなってきますけど、$39.95 かー。むぅ、悩みますなぁ。
視野が狭かった
上記のような考え方だったので、sshでログインしてNFSでマウントされた共有領域に素直に入れようとしたんですけど、インストーラを走らせると警告の嵐。uidとgidを0に設定する事が許可されていない、って言うんです。まぁつまりrootでwheelなアクセス権のファイルやフォルダをそのインストーラは作りたいのだけど、NFSでマウントされている領域のポリシーとしてそれが許されていない、ということでね。
ホトホト困っていたんです。困ったから他のところから片付けていたんですけど、よく考えたら、その領域をエクスポートしているマシンでインストールすればいいんですよね。つまり、NFSでマウントされている場所が
/NFS/sharedDir
だとしたら、そのsharedDirをローカルに持っているマシンが存在しているわけで、そのマシンにしてみれば、普通にローカルにインストールすることになるから当然rootでwheelなファイルを作ることが出来る、と。
その考えに至るまでに1時間かかりましたよ。行き詰まったんで、困りましたよと人に話している時に思い至ったわけですが、人に状況を話すというのは、状況を整理して別の視点をもたらすのに有効だなとか思ってみたりもしつつ、しかし、視野が狭かったなと、そんな感じに無駄に過ごしてた数時間でした。
とかいう愚痴。
Final Cut Pro X の共有の話
FCPXの共有コマンドの話です。試しているバージョンは10.1.4。
ファイルを任意のディレクトリに保存したい時、「マスター」や(上図には無いけど)「ファイルを書き出す」を選ぶのではないかと思います。けれども、その場合、下図のように解像度はプロジェクトサイズに固定されます。
これはフォーマットが「マスタリング」であるときにそうなってしまうようで、これを「公開」のいずれかにすれば、解像度部分がポップアップメニューとなり、いくつかの選択肢から選べるようになります。
とりあえず、プロジェクトの解像度で出すにはファイルサイズがでかくなりすぎるから、適当に小さくして出したいという向きには、「公開」ようのフォーマットから一番ターゲットに近いものを選んで、適当にH.264あたりを選んでおく感じになりますかね。
より細かい制御をしたい場合には、Apple的にはCompressorを買えという事なのでしょう。
しかし、FCPXやCompressorやMotionのGUIがYosemiteに対応した世代になるのはいつになるんでしょうなぁ(クローズボタンなんかがつやつやタイプのGUIなのよね)。
UnityのShaderメモ
Unityのシェーダには三種類あるらしい。
Fixed Function Shaders
UnityのシェーダであるShaderLabで記述する。古い環境で使用される事を想定しているものらしいので、無視してみる。
Surface Shaders
ライティングとシャドウが適用されるシェーダ。ShaderLabとCg,HLSLで記述。
Vertex Shaders, Fragment Shaders
ShaderLabとCg,HLSLで記述される。Vertex Shadersは名前の通り頂点位置を計算する。画面上の位置がこれで決定されて、ラスタライズしピクセルの並びが決定される。その後、そのピクセルを操作するためのシェーダが Fragment Shaders(フラグメントシェーダ)。ピクセルシェーダとも呼ばれる。
ということで、全てのシェーダにはShaderLabが必要となる。ShaderLabのフォーマットは以下の通り。
Shader "MyShader" { Properties { // Unityからシェーダに渡すパラメータを記述 } SubShader { //シェーダーを記述する。 } SubShader { // 複数のハードウェアをサポートする時はSubShaderを必要なだけ連ねる } Fallback "Diffuse" }
最初の"MyShader"がシェーダ名。Unity内で表示されるパスもここでまとめて指定する。myShaders/MyShader とか。
最後のFallbackはSubShaderで記述されたシェーダが動作しなかった場合、とりあえずこれで動作するようにしとけと指定する所。
PropertiesにはUnityからシェーダに渡す値を記述するけど、渡す値は7種類の書き方があるらしい。
- 実数値(最大・最小値有り) name ("display name", Range (min, max)) = number
- カラー値 name ("display name", Color) = (number,number,number,number)
- 2Dテクスチャ name ("display name", 2D) = "name" { options }
- 長方形テクスチャ name ("display name", Rect) = "name" { options }
- キューブマップテクスチャ name ("display name", Cube) = "name" { options }
- 実数値 name ("display name", Float) = number
- 4Dベクトル name ("display name", Vector) = (number,number,number,number)
シェーダ(SubShader内)からは[name]で参照される。UnityのGUIからは(マテリアルインスペクタからは)display name として表示される。等号の後ろの値はデフォルト値。
デフォルト値について、テクスチャ(2D, Rect, Cube)は空の文字列か、"white", "black", "glay", "bump" が内蔵のデフォルトとして用意されている。
サンプルのコードを見ていると、nameにはアンダースコアを頭に付けたものを使用しているんだけど、そんなルールなのかね?
2Dテクスチャと長方形(Rect)テクスチャの違いは、前者は画像の縦横が2^nになっている物で、後者はそうじゃないものという事らしい。
テクスチャにはoptionsが設定できる。利用できる値は
- TexGen texgenmode
- LightmapMode
の二種類らしい。TexGenはテクスチャの座標生成モード。texgenmodeはObjectLinear 、EyeLinear 、SphereMap 、CubeReflect 、CubeNormal のいずれか。
LightmapModeを記述すると、ライトマップパラメータの影響を受けるようになる。
続いてSubShader。この中にパスとサブシェーダタグを記述する。パスは以下の通り。
SubShader { Pass { // } }
どのようにレンダリングエンジンにレンダリングされるかを指定する感じらしい。Fixed Function Shadersではこの中身のみをみるとのこと。だから単純なものはここだけで記述可能かな。
Shader "Custom/SimplePassOnly" { Properties { _Diffuse ("Diffuse Color", Color) = (1, 1, 1, 1) _Specular ("Spacular Color", Color) = (0.5, 0.5, 0.5, 1) _Emission ("EmissionColor", Color) = (0, 0, 0, 1) _MulColor ("Mult Color" , Color) = (1.0, 0.0,0.0,1.0) _MainTex ("Texture", 2D) = "white" { } } SubShader { Tags { "Queue" = "Geometry" } //Queueは描画の順番を判定する。Geometryはデフォルト値。 Pass { Material { Diffuse [_Diffuse] Ambient ( 0.0, 0.0, 0.0, 1.0 ) //値を直接しているする時とプロパティを参照する時、()と[]の違いがある Specular [_Emission] Shininess 0.1 //0から1の範囲 Emission [_Emission] } Lighting On //スペキュラーが適用されるか否か SeparateSpecular On Cull Back //この設定は表面描画。とれる値は→(Back , Front , Off) ZWrite On //深度バッファへの書き込み(On, Off) ZTest LEqual // 深度テスト。奥行きを基準とした評価をし、合格したら描画される。LEqual以外はあまり使われない。 //Offset 0, -1 書き込む深度値をずらす時に使う、ということらしい。 SetTexture[_MainTex]{ ConstantColor [_MulColor] combine Texture * Constant //_MainTexに_MulColorを乗算で乗せている。 } //AlphaTest Less 0.5 アルファの値を見て、描画を決定する。テクスチャのアルファチャンネルで穴を開けるとかに利用。 //Blend SourceBlendMode DestBlendMode 後で勉強する。 //Fog{ } 後で勉強する。 } } Fallback "Diffuse" }
まぁしかし、これだと当然出来ることも限られてくるわけで、そうするとサーフェースシェーダに手を出さざる得なくなるらしい。
SubShaderに CGPROGRAM~ENDCG を書いておいて、そこに挟まれた範囲がシェーダとなる。さらにそのシェーダがサーフェースシェーダであることを示すために、#pragma surface という指示を与えてやるようだ。
#pragma surface surfaceFunction lightModel [optionalparams]
surfaceFunction、lightModel、 [optionalparams] を適切に指定してやる。
surfaceFunctionはシェーダの関数名。lightModelはシェーディングモデルの指定かな。"Lambert"か"BlinnPhong"となる。[optionalparams]はオプションなんだけど、マニュアルには19個程も記述されてた。サーフェイスシェーダの記述 [Unity リファレンスマニュアル]
CGPROGRAM #pragma surface surf Lambert void surf( Input IN, inout SurfaceOutput o ) { } ENDCG
というわけで、基本的にはこんな形。void surf( Input IN, inout SurfaceOutput o ) { } に渡すInputや出力するSurfaceOutputを指定する。これらは構造体でいろいろ決まりごとがある模様。
Shader "Custom/SimplePassOnly" { Properties { _BaseColor ("Base" , Color) = (1.0, 0.0, 0.0, 1.0) _MainTex ("Main Texture", 2D) = "white" { } _SubTex ("Sub Texture", 2D) = "white" { } } SubShader { Tags { "Queue" = "Geometry" } //Queueは描画の順番を判定する。Geometryはデフォルト値。 CGPROGRAM #pragma surface surf Lambert float4 _BaseColor; //Propertiesで設定した色を取得 sampler2D _MainTex; //Propertiesで設定したテクスチャを取得 sampler2D _SubTex; //入力の構造体 struct Input { float2 uv_MainTex; //Propertiesで設定したテクスチャを取得。uvXXXXという形式で取得するみたい。 float4 screenPos; //スクリーンの座標系? }; void surf( Input IN, inout SurfaceOutput o ) { //oが出力の構造体 o.Albedo = half3(_BaseColor) * tex2D( _MainTex, IN.uv_MainTex ).rgb ; //アルベドを設定。拡散反射光であり、いわゆるディフューズと同義かね。 float2 screenUV = IN.screenPos.xy / IN.screenPos.w; //よく分からないけど、wで割ることで、ビューポートに対して0から1に収まる座標系に変換されるらしい。 screenUV *= float2(2,3); //その上で繰り返す。 o.Emission = tex2D( _SubTex, screenUV ).rgb * 0.5; //その座標系で貼られたテクスチャをエミッションに適用。 } ENDCG } Fallback "Diffuse" }
んじゃ、これを半透けにしましょう、って時。あるいはテクスチャのアルファチャンネルで抜きましょうって時。
この場合、Tags { "Queue" = "Transparent" } とする必要があるのと、#pragma surface surf Lambert alpha とする必要がある。alphaを追加してアルファ ブレンディングモードにしている。その上で、o.Alphaに適切な値を指定する。
Shader "Custom/SimplePassOnly" { Properties { _BaseColor ("Base" , Color) = (1.0, 0.0, 0.0, 1.0) _MainTex ("Main Texture", 2D) = "white" { } _SubTex ("Sub Texture", 2D) = "white" { } } SubShader { Tags { "Queue" = "Transparent" } //描画するタイミングを半透けのもんに適したものに指定。 CGPROGRAM #pragma surface surf Lambert alpha //アルファブレンディングモード float4 _BaseColor; //Propertiesで設定した色を取得 sampler2D _MainTex; //Propertiesで設定したテクスチャを取得 sampler2D _SubTex; //入力の構造体 struct Input { float2 uv_MainTex; float3 worldRefl; }; void surf( Input IN, inout SurfaceOutput o ) { half4 color = tex2D( _MainTex, IN.uv_MainTex ) ; //テクスチャのカラー(rgba)を取得 o.Albedo = color.rgb * half3(_BaseColor) ; //Propertiesで設定した色をテクスチャに乗算してる。 o.Emission = tex2D( _SubTex, IN.worldRefl ).rgb * 0.5; //反射っぽい表現。 o.Alpha = color.a; //透明度の指定。この場合、テクスチャのアルファチャンネルから。 } ENDCG } Fallback "Diffuse" }
とは言え、裏面が描画されていないから、ちょっと不自然である。裏面も描画させるには、裏面を描いてから表面を描くようにするそうで。
Shader "Custom/SimplePassOnly" { Properties { _BaseColor ("Base" , Color) = (1.0, 0.0, 0.0, 1.0) _MainTex ("Main Texture", 2D) = "white" { } _SubTex ("Sub Texture", 2D) = "white" { } } SubShader { Tags { "Queue" = "Transparent" } //裏面描画***************************************************** Cull Front CGPROGRAM #pragma surface surf Lambert alpha float4 _BaseColor; sampler2D _MainTex; sampler2D _SubTex; struct Input { float2 uv_MainTex; float3 worldRefl; }; void surf( Input IN, inout SurfaceOutput o ) { half4 color = tex2D( _MainTex, IN.uv_MainTex ) ; o.Albedo = color.rgb * half3(_BaseColor) ; o.Emission = tex2D( _SubTex, IN.worldRefl ).rgb * 0.5; o.Alpha = color.a; } ENDCG //表面描画***************************************************** Cull Back CGPROGRAM #pragma surface surf Lambert alpha float4 _BaseColor; sampler2D _MainTex; sampler2D _SubTex; struct Input { float2 uv_MainTex; float3 worldRefl; }; void surf( Input IN, inout SurfaceOutput o ) { half4 color = tex2D( _MainTex, IN.uv_MainTex ) ; o.Albedo = color.rgb; o.Emission = tex2D( _SubTex, IN.worldRefl ).rgb * 0.5; o.Alpha = color.a; } ENDCG } Fallback "Diffuse" }
こちらは反射が不自然なので、反射表現のためにCubeMapをしてみる。Properties でCubeMapの取り口を作るのは、
_Cube ("Cubemap", CUBE) = "" {}
となる。でもって、先のコードの出力部分の tex2D( _SubTex, IN.worldRefl ).rgb * 0.5 部分を texCUBE (_Cube, IN.worldRefl).rgb にする。
Shader "Custom/SimplePassOnly" { Properties { _BaseColor ("Base" , Color) = (1.0, 0.0, 0.0, 1.0) _MainTex ("Main Texture", 2D) = "white" { } _SubTex ("Sub Texture", 2D) = "white" { } _Cube ("Cubemap", CUBE) = "" {} //キューブマップの取り口 } SubShader { Tags { "Queue" = "Transparent" } //裏面描画 Cull Front CGPROGRAM #pragma surface surf Lambert alpha float4 _BaseColor; sampler2D _MainTex; samplerCUBE _Cube; //Propertiesで設定したキューブマップを取得 //入力の構造体 struct Input { float2 uv_MainTex; float3 worldRefl; //ワールド座標系? }; void surf( Input IN, inout SurfaceOutput o ) { half4 color = tex2D( _MainTex, IN.uv_MainTex ) ; o.Albedo = color.rgb * half3(_BaseColor) ; o.Emission = texCUBE (_Cube, IN.worldRefl).rgb * 0.5; //反射っぽい表現。キューブマップ。 o.Alpha = color.a; //透明度の指定。この場合、テクスチャのアルファチャンネルから。 } ENDCG //表面描画 Cull Back CGPROGRAM #pragma surface surf Lambert alpha float4 _BaseColor; sampler2D _MainTex; samplerCUBE _Cube; //入力の構造体 struct Input { float2 uv_MainTex; float3 worldRefl; }; void surf( Input IN, inout SurfaceOutput o ) { half4 color = tex2D( _MainTex, IN.uv_MainTex ) ; o.Albedo = color.rgb; o.Emission =texCUBE (_Cube, IN.worldRefl).rgb * 0.5; o.Alpha = color.a; } ENDCG } Fallback "Diffuse" }
だいぶ自然になったかなというところ。
とりあえずはこんな具合ですかなぁ。
いつかは利用してみたかったのだがね
とかうだうだ書いてみたのは、こんな写真を撮れる場所にいたからでした。
まぁ、たまたまね。時間が合ったってだけなんですけど、DD51の重連に引かれるカシオペアの姿はなかなかの迫力でしたよ。
というわけで、そのあたりにいました。天気に恵まれて、雪に振り付けられるという事はなかったのだけど、雪に慣れてない身としては、足下がおぼつかないのでした。
でも、風がないせいか、あるいは最高気温がちょっと高めだったからか(街に表示されていた温度計は3度とか1度とか出てた)、それほど寒さは感じなかったなぁ。むしろ、地元に帰ってきて外を歩いている時の方がよほど寒かった。風のせいかな、やっぱ。
今度はいい季節に北海道に行ってきたいですな。