‘プログラム’ カテゴリーのアーカイブ

電力使用状況なブログパーツ(4)

 プログラム,
 公開日:2014年11月6日 / 更新日:2016年7月26日

Yahooの「電力使用状況API」終了に伴い、2016年9月30日以降は本ブログパーツもサービス終了となります。

★2016年7月26日追記。
こちらに告知が出ていました。
・東北電力:2016年3月31日に更新停止。
・中部電力:2016年6月30日に更新停止。
・2016年9月30日(金)を以って「電力使用状況API」を終了。
道理で更新されない訳だ(^_^;)
ということで使用できるのは10月迄となります。
ご了承ください。

★2016年4月20日追記。
一部の電力会社について、
データの更新状況が変わったようです。
理由はよく分かりません。
とりあえず対処してみましたが、
更新が停滞している場合はその旨を表示するようにしました。

★2014年12月18日追記。
自分のサイトでは動いているのですが、
他サイトで導入した場合におかしくなっていたようです。
改善してみました。失礼しました。

★2014年11月25日追記。
備忘のためのメモ。
callbackを指定してJSONP形式を要求しているはずなのに、
なぜかMIMEが”application/javascript”ではなく
“application/json”になることがあるので、
自前のPHP経由に変更しました。ちょっとナゾ・・・。

以前に、
電力使用状況&電気予報なブログパーツというのを作りましたが、
YAHOOの「電気予報API」のサービスは
2014年10月31日をもって終了となりました。

東日本大震災に関連する情報を提供する目的で、
期間限定で公開されていたAPIだったので、
一定の役目は終えたというところなのでしょう。

ブログパーツで使っているもう一つのAPIに
電力使用状況API」があるのですが、
連休を挟んだここ1週間ほど更新が止まっていたので、
これも終了なのか!?
と思ってたら更新されるようになりました(^_^;)
もしかしたら休日は更新を休止してるのかな?

ということで、
電気予報な情報の表示を無くして、
電力使用状況だけのバージョンに作り変えました。
サイズがよりコンパクトになりました。

Yahooの電力使用状況APIを使用していますので、
Yahooのクレジット表記が必要となっています。ご了承ください。

ブログパーツの埋め込みスクリプトは以下の通りです。
無料でご利用いただけます。

北海道電力。

東北電力。

東京電力。

中部電力。

関西電力。

九州電力。

three.jsで遊んでみる(32)

 プログラム,
 公開日:2014年10月13日 / 更新日:2014年10月15日

だいぶ前から、それとなく気づいていたことに、
本家MMDに比べてレンダリング結果がなんか変
というのがあったりします(^_^;)
今回それなりに改善できたので書いてみたいと思います。

ところで、
IKとか物理演算とかの技術的な興味から始めたthree.jsでMMDですが、
ミクさんを踊らせることが目標だったので、
自分の中ではすでに目標達成な感じだったりします。
趣味でやっているので再現性にはあまりこだわらなかったりしてますが、
一方で気になり出すとどうにかしたくなる性分だったりもします。

さて、
レンダリング結果が変なのは前からどうにかしたいなと思っていたわけですが、
比較検討するためのLighting設定とかが分かりませんでした。
ところが先日PmxEditorの表示設定にそれらの情報があることを見つけました。
何度も使っていたのに今頃になって気づきました(^_^;)

PmxEditorでのデフォルトの表示設定では、
環境ライト色 = (255,255,255)
方向ライト色 = (127,127,127)
方向ライト向き = (-0.5,-1.0,0.5)
視野角 = 25度
という感じになっていました。

これを基準に比較検討することにしました。
ただし「向き」はthree.jsで扱うために右手系へ変換します。
つまり、(-0.5,-1.0,-0.5)にします。
またカメラ位置は不明だったので、
だいたい同じ感じに見えるように手動調整しました。

実際にやってみると、three.js側はちょっと暗めな感じ。
PmxEditor側は照明強度を少し強めにしている模様です。
方向ライトのIntensityを1.1くらいにしてみました。

で、比較結果は以下の通り。
左がPmxEditor、右がthree.js。
PmxEditorでのアンチエイリアスは無効にしてます。
※クリックすると実サイズで比較画像を参照できます。フルHDくらいのサイズがあります。

0-1

こうして比べて見ると、だいぶ異なってますね。
シェーダーのコードを一から見直したほうが良さそうです(^_^;)
ということでWebの情報を漁ってみたところ、こちらを発見しました。
これは大いに参考になりますね。
もっと早くこちらの情報に気づいていれば・・・。

そんなわけで大きく3つの問題が判明しました。
1)toonマップのアドレス計算がまちがってる。
2)toonマップの適用タイミングがまちがってる。
3)sphereマップのアドレス計算が不十分。
ざっくり言うと、
toon掛けた後にspecularを適用した感じになってしまっています。
正しい順番はその逆でした。

1)と2)については、
できるだけthree.jsの機能に対応するように改造した関係で、
勘違いや考慮不足が原因だったようです。
three.jsのシェーダーのコードは、方向ライトだけでなく
ポイントライトやスポットライトなどに対応しているので複雑だったりします。
ちなみにこんな感じ。phongを改造してます。
3)については、テクスチャの上下逆問題の絡みでした。
この回の投稿でも書いたりしてますが、
どうにも対応が中途半端になってしまうようなので(^_^;)
texture.flipY = falseに統一することにしました。

ということで改善した結果は以下の通りです。
右の方がtoonのコントラストが微妙に弱めな感じがしますが、
概ね同じような感じになってくれました。

1-2

改善後の動作テストを見るにはこららからどうぞ。
なお、テストでは以下のデータを使用させていただきました。
モデルはMMD同梱のメタル服なミクさん、
モーションはこちら、カメラモーションはこちら

WebGL対応のブラウザで見てください。WindowsのChromeで確認しています。PCパワーもそれなりに必要となるかもしれません。反応がない場合は、リロードして再度試してみてください。

やたらとサーバーが重いことがあります・・・。
そんな時は、激しく気長に待ってみてください(^_^;)

shadow などのチェックを全て外し、outline scale をゼロにすると動作的に一番軽くなります。ブラウザの拡張機能を一時的に無効にすると、さらに軽くできるかも。

three.jsで遊んでみる(31)

 プログラム,
 公開日:2014年9月21日 / 更新日:2014年10月22日

とあるモデルでのモーションの挙動がオカシイということで調べてみた所、
どうやら「付与」がうまく行ってない感じ。
付与に関してはうまく行っているようでダメな場合があり、
よく分からない状況だったりしました。
ところが先日色々いじくってたら、
なんかうまく行くようになりました。

当初は素直に、
対象ボーンをA、参照するボーンをBとして、
Aの変形量 += Bの変形量 × 付与率
とやったりしたのですが、どうもうまく行かない。
次に、
ある描画フレームとその次のフレームでの変形量の差分を求めて、
Aの変形量 += Bの変形量の差分 × 付与率
とやったらうまく行ったのですが、モデルによってはダメなことも。
そして今度は、
バインドポーズ時との差分でやってみたらイイ感じになりました。
バインドポーズ時の各ボーンの回転量はゼロなので、
当初のやり方でも回転に関しては間違ってないのですが、
バインドポーズ状態に初期化してないことが原因でした。
初期化してないので延々積算してしまっていました。
要するに初期化のし忘れ・・・でした(^_^;)

ということでまとめると、
1)各ボーンをバインドポーズ状態に初期化
2)Aの変形量 += Bの変形量の差分 × 付与率
を毎フレームやれば良い感じ。
実際には1)と2)の間で Bone Skinning とか IK とかをやります。
そして回転に関しては基準の回転量がゼロなので、
差分計算は省いても大丈夫なことになります。

「回転付与」に関してはおそらく解決だとは思いますが、
試すのに良さげなデータを持ってないため、
「移動付与」や「ローカル付与」は未検証です。
後で問題が起きるかも?(^_^;)

ということで改善後の動作テストを見るにはこららからどうぞ。
改善前はこららです。
確かにヒジの曲がりが直ってる感じです。

なお、テストでは以下のデータを使用させていただきました。
モデルはこちら、モデルモーションはこちら、カメラモーションはこちら

それから今回はもう一つ問題がありました。
“瞳”の表示がなんかオカシイ・・・。
調べてみると、透過オブジェクトの描画順に起因する問題でした。

ところで three.js では、
透過オブジェクトは奥から手前へ、
不透過オブジェクトは手前から奥へ、
の順で描画するようになっています。

透過オブジェクトの描画順については、
そのようにしないと矛盾が起きるのは理解しやすいと思います。
不透過については奥から手前でも問題ないのですが、
手前から奥にすると効率がよくなります。
奥行きを表すZバッファの値を比較することで、
実際の描画量を減らせる効果を期待できるからです。

明示的に透過指定のあるマテリアルや、
テクスチャが透過成分を含むマテリアルの場合に、
透過フラグを指定するように今までやってました。
大抵のモデルではそれで問題は起きない感じなのですが、
一部のモデルではうまく行かない場合があるようです。
そこで、
全マテリアルの透過フラグを強制的にオンにする機能を追加して、
透過問題に対応できるようにしました。

でも、よく考えてみると、
材質モーフとかで透過度が変化することは十分ありそうなので、
描画効率が落ちるかもしれないけど
デフォルトでオンにしてしまった方がよさそうです。
透過になるかどうかは静的ではなく動的にならざるをえないので、
それに対応できるようにしないとうまくない感じですね。
ただ現状では頂点モーフしか対応してなかったり・・・(^_^;)
それ以外の種類のモーフはいずれどうにかしたいですね。

Crayon Syntax Highlighter を使ってみた。

 WordPress, プログラム
 公開日:2014年8月26日 / 更新日:2014年8月29日

WordPressでソースコードをイイ感じに表示してくれるプラグインとして、
今までずっと「Syntax Highlighter for WordPress」を使ってきましたが、
先日とあるサイトで見たソース表示な感じが良さげだったので、
気になって調べたところ、
それが「Crayon Syntax Highlighter」でした。
そんなわけで使ってみようと思った次第です。

使い方はこちらを参考にしてみました。
↓とりあえず試してみた感じがこれ。

表示オプションが色々あって迷ってしまいます(^_^;)
ツールバーを自動でshow/hideできたり、
折り返された行を伸ばせたりと機能が豊富です。
<code>タグで囲った所を良さげにできたりもします。

表示テーマも豊富に用意されています。
以前と見た感じが同じになるように「Familiar」テーマを選んでみましたが、
折り返された行が伸びた時に背景が抜けてしまう問題がありましたので、
テーマをduplicateして行のNormal時の背景色を指定したら直りました。
(結局テーマは「Classic」に落ち着いたけど(^_^;))

多くの言語に対応しているのも良いですね。
タグに指定するID名は設定画面で確認できます。
glslが無かったのは残念でしたが、
defaultにしておけばどうにかなるみたいです。

ソースコードのコピーの際にCtrl-Cでやらんといかんのがイマイチかな。
コピーボタン押したらクリップボードに入れてくれる方が分かりやすいと思う。
一部の日本語表示はpoeditで調整しました。

なお、
[php][/php]といったミニタグをサポートしているので、
「Syntax Highlighter for WordPress」からの移行も楽だったりするのですが、
こちらに書かれてあるように
ミニタグや以前の古いタグ [crayon][/crayon]は非推奨なので、
<pre></pre>を使う記述にする方がよさそうなのですが、
もしかしたら元に戻すかもしれないので
とりあえずミニタグのままにしておきます(^_^;)

全面的にCrayonへ移行させる場合は、
設定画面にある「Show Crayon Posts」を押すと
Crayonの対象になる投稿の一覧がでるので、
それらを <pre>タグなスタイルへ変更すれば良さそうです。
ただし手間暇かかりそうですね。
「Convert Legacy Tags」で一括変換してくれそうなんだけど試してません。

three.jsで遊んでみる(30)

 プログラム,
 公開日:2014年8月23日 / 更新日:2014年8月27日

とあるMMDなモデルがうまく表示されないらしいので調べてみました。

・・・なるほど。
DDSなテクスチャファイルを使ったPMXでしたか。
以前にも書いてますが、
texture.flipY = false を基本にしないとやはりダメか(^_^;)

ところで、
WebGLRenderer.jsでは以下の様な感じになっており、

texture.flipY は gl.UNPACK_FLIP_Y_WEBGL に対応しています。
名称からするとWebGL固有なパラメータなのかな?
three.js ではデフォルトで有効になっていますが、
その理由はよく分かりません。

以前では flipY = false にすると影響が出そうなので止めてしまいましたが、
よく調べてみたら影響はTOONマップだけだと分かりました。
Fragment Shader においてマップ時のV座標を逆転させればOKだけど、
コードがちょっとだけ増えます。
そこでTOONマップだけは flipY = true のままで行けるようにしました。
TOONテクスチャにDDSが使われることはないと思うので大丈夫かと思います。
思ったよりアッサリと解決できました(^_^;)

ただ、
今回のモデルではもう一つ問題が起きていました。
スカートの裏が抜けてしまうのです。
原因は両面描画がうまく行えていないことでした。
実装はしてあったのですが、そういえば検証してませんでした。
今になって問題が露呈しました(^_^;)
glのステータスがちゃんと反映されるように直して解決。

あと、
ヒジの曲がりが何かオカシイ感じがしてます。
ヒジには付与が導入されているのですが、
残念ながら完全にはうまく行えていないようです。うむぅ。
むしろを付与をオフった方がマシになる感じ(^_^;)

なお、モデルのREADMEにはSDEFを使用していると書いてあるのですが、
データ上はSDEFは使われていませんでした。ちょっとナゾ。
といってもSDEFには未だ対応してないけど(^_^;)
また、ほとんどのマテリアルに両面描画のフラグが設定されているのですが、
実際にはスカートと髪の一部だけに適用すれば良さげな感じなので、
そのように調整しました。無駄な描画が減るはず。
さらに、透過成分の無いDDSファイルについては
ロード時間を減らすためにDXT3からDXT1に変更しました。

ということで動作テストを見るにはこららからどうぞ。

なお、テストでは以下のデータを使用させていただきました。
モデルはこちら、モデルモーションはこちら、カメラモーションはこちら

WebGL対応のブラウザで見てください。WindowsのChromeで確認しています。PCパワーもそれなりに必要となるかもしれません。反応がない場合は、リロードして再度試してみてください。

やたらとサーバーが重いことがあります・・・。
そんな時は、激しく気長に待ってみてください(^_^;)

shadow などのチェックを全て外し、outline scale をゼロにすると動作的に一番軽くなります。ブラウザの拡張機能を一時的に無効にすると、さらに軽くできるかも。

20140823.046