パスワードを忘れた? アカウント作成

Ledさんのトモダチの日記みんなの日記も見てね。 ログインするとコメント表示数や表示方法をカスタマイズできるのを知っていますか?

13456909 journal
数学

Ledの日記: 停止するか判定できないような関数

日記 by Led

このコメントの話、このコメントの口調は妙に防衛的に感じるし、親コメントACを擁護したいわけでもなく、直接かかわりたくないので「ログインユーザーのみ」の日記で。

「停止するか判定できないような関数」には「チューリング機械の空入力停止問題」とかいうのがあるらしい。要するにC言語で適当にチューリング機械の定義を与えておいて、空入力でのTMの動作を模倣する関数が該当する。ある程度ゴチャゴチャしたものを作ってやれば、人間が見て判断するのはコスト的に無理になる。機械で判定しようとしても、十分長い時間たった後で停止するTMと、永遠に停止しないTMを区別することができない。

他にもPostの対応問題とかいうのがあるらしい。

13454804 journal
日記

Ledの日記: ニコ動に投稿してきた感想 4

日記 by Led

このストーリーに乗り遅れたので日記で。

ニコ動のデメリットについては今更言うことはないと思います。表のストーリーでいっぱい書いてあるしその通りだと思います。

動画を投稿する側のメリットとして、ニコ動システムは「コメントが流れる」という点があります。システム的にはそこにしかメリットを感じていないのですが(追記:ニコニコモンズやコンテンツツリーもニコ動システムのメリット)、動画のどこが良くてどこがアレなのかを見やすいのは、手探りで動画を作る過程ではなかなかの安心感があります。次回作の参考にしやすい。今のYouTubeをチェックしていないのですが、少なくとも昔のYouTubeみたいな動画の下にコメントリストが付く形では不十分かなあと思います。

システム以外のメリットとしては、大体反応が予想できるユーザーが見ている(という気になれる)点ですね。そこにいる人たちはこういうのを喜んでくれるんじゃないかな、とか。別にYouTubeでもいいんですけど、なんとなく住み慣れた村から出るのもどうかなという感じでしょうか。

ニコ動に投稿してた人でもYouTubeメインにして大量再生稼いでる人もいらっしゃいます。あんまりデメリットが増えると、あるいはもう既に、投稿先を見直した方がいいのかもしれないことを否定しようというものではありません。

----

最近こっちに来てなかったので。こんなの投稿してます。まだ新作も出したいなと思っています。

----

ニコニコモンズやコンテンツツリーもニコ動のメリットでした。忘れてた。自分の作ったものを使ってもらったことが通知される仕組みも使ってて心地がよいものです。

13441106 journal
日記

Ledの日記: AIでCAPTCHA突破率66% 2

日記 by Led

これ

画像認識関係はAIが強いという話だったが、もうCAPTCHA程度は
人間とかなり近いレベルで認識できてしまうのだな。
現行のCAPTCHAより難しくすると人間様が読めなくなりそうだし。

そうすると後は何が残るかね。ビルゲイツ認証とかも突破できそう。
もう突破されてるのかな。

13438466 journal
日記

Ledの日記: Oliver日記リンク切れ

日記 by Led

スラド右側に(多分)表示されているスラッシュボックスの「クイックリンク」中にある「Oliver日記」はリンク切れのようだ。

正しいリンクはこちら。もう10年も更新されてないから誰も見ないと思うけど。

-----

「スラッシュボックス」ではなく、今は「スラドボックス」というようだ。
slashdot.jp からsrad.jpに変更した時に一緒に名称変更したのかな。

13436822 journal
スラッシュドット

Ledの日記: 日記の日付指定閲覧 4

日記 by Led

昔の/.jp日記を読みたくなる時がある。

「続きを表示」をクリックし続けてさかのぼることもできなくはないが、きつい。
そういう人のためかどうかは知らないが、日付を指定する機能がついている。

http://srad.jp/index2.pl?fhfilter=%22author:Led%22+journal&startdate=20120401&view=journal&color=black

authorを自分の名前にし、startdateで指定した日からさかのぼって日記を参照できるらしい。この機能はまだ生きている。

13170921 journal
プログラミング

Ledの日記: MME/MMMエフェクト関連の詳細まとめ

日記 by Led

MME用の.fxファイルを自動変換してMMM対応するプログラムを書いていたら、いろいろ不思議な仕様やバグと思われるものまで出てきた。ソースコード中にコメントで書いていたりするが、MMM用にエフェクトを書きたい人のためにメモしておく。(作者のMoggさんは最近多忙らしくMMMも1年以上更新されていない。知らせたとしてすぐに更新されるわけでもないと思われるので、いろいろ洗い出してから知らせることにする。)

-------------------
MMEの仕様で注意すること

●float4 EgColorとfloat4 SpcColor

この二つの変数はREFERENCE.txt(マニュアル)にないが、古いMMEで材質モーフ後のエッジ色、反射色と反射強度を取得するのに使われていて、この仕様はMME v0.37でもまだ生きている。MMMでは材質モーフ後の色しか取得しないので、MMMのマニュアルに従って変数を設定すれば移植できる。

--------------------
MMM用のエフェクトを書く際に注意すること

●ライト関連のジオメトリ変換行列の制約

MMMのエフェクト開発マニュアル(この執筆時点でv1系はv1.2.7.2が最新)にはライト関連の座標変換行列を取得するには
float4x4 LightWorldViewProjMatrix : WORLDVIEWPROJECTION < string Object="Light";>;
のように書いても取得できるとの記述がある。が、実際やってみるとどうやら< string Object="Light";> のアノテーション部分が無視されているようだ。(アノテーションがあってもなくても同じ動作に見える。) ワークアラウンドとして、最もよく使うライトのWORLDVIEWPROJECTIONに関しては代わりにLIGHTWVPMATRICESというセマンティクスが用意されている。これを使って

float4x4 LightWorldViewProjMatrices[MMM_LightCount] : LIGHTWVPMATRICES;
#define LightWorldViewProjMatrix LightWorldViewProjMatrices[0]

などと書くべきであるようだ。

なお、こうやって計算したLightWorldViewProjMatrixでもz座標の計算が不安定である。OFFSCREENRENDERTARGETの描画で、この行列を掛け算した位置ベクトルのz座標を用いて描画を行うとひどくチラついてしまう。(MMMのUIから当該OFFSCREENRENDERTARGETを表示すると綺麗に表示されるので中々気づけない) なお、MMM添付のSampleBase.fxmでは、z座標だけ別に計算しなおしている。

また、

float4x4 LightWorldMatrix: WORLD < string Object="Light"; >;
float4x4 LightViewMatrix : VIEW < string Object ="Light"; >;
float4x4 LightProjMatrix : PROJECTION < string Object ="Light"; >;

これらの記述も同様にアノテーションを無視したような動作をする。

●DefaultEffectで none, hideばかりのOFFSCREENRENDERTARGETがUIから省略される

デフォルトで指定するシェーダが無いOFFSCREENRENDERTARGETはMMMのUIからアクセス不能になってしまう。エフェクト作者の立場からこれを防ぐには、DefaultEffectに

self=dummy.fxm

のような指定を追加して、さらに何も描画しないエフェクトdummy.fxmを作成しておく。なお、UIにはデフォルト指定されたファイル名が表示されるので、OFFSCREENRENDERTARGETの名前を(dummyの代わりに)エフェクトのファイル名にすると使いやすくなるだろう。
(なお、MMEではselfは「このエフェクトが割り当てられたモデル」だが、MMMでは必ずポリゴンを持たない「エフェクトオブジェクトと呼んで良さそうな何か」になる。selfに何を指定してもMMMでは描画に影響ない、はず。)

●エッジ色のα値について

MMM添付のSampleBase.fxmではエッジ用のtechniqueで
AlphaBlendEnable = FALSE;
AlphaTestEnable = FALSE;
という指定がされているが、AlphaTestEnable=TRUEに書き換えてやって、ピクセルシェーダでα値を0にすると描画をストップできるようだ。ピクセルシェーダ側でポリゴンに穴をあけたい場合などに使える。なお、AlphaBlendEnable=TRUEとしても無視されるようだ。
MMEではエッジであっても透過処理をしてくれるので、ここも差異として記録しておく。

●UseToonおよびuse_toonの動作の差異

MMEとMMMではトゥーン指定がない材質の描画でUseToonおよびuse_toonの真偽が異なるようだ。このせいでMME用のエフェクトをMMMに持ってくるとモデルの表示が醜くなってしまうことがある。回避するには、まずMMMの特殊パラメータ

bool usetoontexturemap; // Toonテクスチャフラグ

をエフェクトの先頭付近に追加しておいて、その後MMDPass="object"のピクセルシェーダでUseToonの値が入っている変数(含use_toon)を

(use_toon && usetoontexturemap)

のように書き直す。

●シャドウバッファ

MMEではセルフシャドウに使うバッファにアクセスする際に

sampler DefSamp : register(s0);

と書く約束になっている(DefSampは別の名前でもよい)。が、MMMでは違うものを使う。MMMではMMM_GetSelfShadowToonColorとMMM_GetToonColorの2つの関数を使ってセルフシャドウの計算をする方法が推奨されているが、それでは自動変換が大変やりづらい。

代替案を探すためMMMをよく観察した。MMMではデフォルトでMMM_SelfShadowDepthMap1というテクスチャが定義されていて、これにアクセスするとMMDのセルフシャドウに似た計算ができる。ただし、計算値が違うため換算処理を書いてやらなくてはならない。MMDのデフォルトシェーダにとても近い描画をするMMEエフェクトのfull.fxにて、シャドウバッファ座標のz座標を

Out.ZCalcTex.z = (length(LightPosition - SkinOut.Position) / LightZFar);

に修正する必要がある。また、SKIIの値を5倍程度にしなければ、モデルとカメラの距離が離れるとすぐに影が薄く消えてしまう。
-----------------------
(2017_06_09追記)

float4 EdgeColorという変数をグローバルで定義するとMMEでもMMMでもエッジの色を取得できるが、MMMではその非透明度が1ではなく2程度になっている。対策としてEdgeColorを参照しているところを見つけたら全部 saturate(EdgeColor)に修正する。
-----------------------
(2017_07_04追記)

実はHLSLのテクスチャサイズには限界があった。MMEでは限界を超えたサイズのテクスチャサイズを適当にごまかすようだが、MMMではエラーを吐いて落ちる。なお、MMMではテクスチャサイズの限界は1辺8192ピクセルのようだ。
----------------------
他にもまだ出てくると思われるが、気が付いたときに書き足す。

13006693 journal
プログラミング

Ledの日記: MMEfx2MMM

日記 by Led

背景
MikuMikuDance+MMEで使用する.fxファイルとMikuMikuMoving(MMM)で使用する.fxmファイルはどちらも基本的にHLSLで書くことになっているが、いくつか仕様に差異があるため、一つのシェーダをそのまま相互利用はできない。このためコミュニティのシェーダ開発者は手作業で相互の対応を行っているか、あるいは片方(たいていの場合MMD+MME)でしか利用できないという現状がある。つまりMMD+MMEの方がメジャーで、3Dモデルも付帯ツールもMMDでの動作をターゲットにして作られることが多い。このためMMMでの動画制作には不遇な面もある。

一方で、MMMはUI上優れた点もあるので、動画作成者の中にはMMMをメインで使っている人もいるようだ。例えば複数ボーンの操作であるとか、ボーンやカメラの多段化、字幕などと呼ばれる機能がMMMでは標準で搭載されているのだが、MMDで同様のことをやろうとするとひと手間余計にかかる。

そういうわけでMMD+MME用に書かれているシェーダをMMMで使用するためのフィルタがあると便利である。また、MMD+MME用に作られて配布されている.fxファイルは「非営利の利用なら自分で勝手に編集して再配布してもいいよ、商用の時だけ相談してね」という程度の緩い使用許諾であることが多いのでライセンス上の問題は発生しにくそうだ。そういうわけで、MMD+MME用のシェーダ.fxファイルを食わせるとMMM用のシェーダを吐くような、まあそういうものを作りたいな、というわけ。

現在の進捗状況
MMD+MME用シェーダをMMM用シェーダに書き換える手作業を何回かやってみた。
機械的にできそうなシェーダの書き換えルールを洗い出した。
自動化のためのツールをC#で書いている。

なお、開発言語をC#とするのはMMMにプラグイン機能があって、MMMプラグインはC#で書くことになっているため。余裕があればMMMプラグインとして配布するのがしっくりくるだろう。
-----

MME用の.fxファイルをMMMに持っていくときの手順を忘れてた。ツイッターには書いたがすぐに検索しづらくなるのでこっちに転記、MMM対応とはつまり

エッジ描画処理を修正
// 輪郭描画用テクニック
technique EdgeTec < string MMDPass = "edge"; > {
        pass DrawEdge {
                // MMM対応ここから ///////////////////////
                AlphaBlendEnable = FALSE;
                AlphaTestEnable = FALSE;
        // MMM対応ここまで ///////////////////////

                VertexShader = compile vs_2_0 ColorRender_VS();
                PixelShader = compile ps_2_0 ColorRender_PS();
        }
}

各頂点シェーダの引数に以下を追加
    MMM_SKINNING_INPUT IN,

各頂点シェーダの最初に以下を書く

    MMM_SKINNING_OUTPUT SkinOut = MMM_SkinnedPositionNormal(IN.Pos, IN.Normal, IN.BlendWeight, IN.BlendIndices, IN.SdefC, IN.SdefR0, IN.SdefR1);
    その後、頂点シェーダの引数変数にSkinOutのメンバから代入

エッジの頂点シェーダだけ、最初にこれを追加
 Pos += float4(SkinOut.Normal, 0) * IN.EdgeWeight * EdgeWidth * distance(SkinOut.Position.xyz, CameraPosition);
なお、Posは各シェーダの変数名(POSITIONセマンティクス)に合わせる。

MMDPass="object"のtechniqueを消した後 MMDPass="object_ss"をMMDPass="object"に書き換える

MMMのエフェクトではuse_subtextureは未定義なのでグローバル変数で常にfalseとして定義する。サブテクスチャを使いたいときどうするかは今後の課題。

---
MMM_GetToonColorとかMMM_GetSelfShadowToonColorとかを無視してfull.fxのシャドウ処理をベタッと貼っても動く。ただしLightDirectionをLightDirection[0]にする。

---
以下のライト関連の記述はMME用そのままでも動作するらしい。
// ライト関連
//float4x4 LightWorldViewProjMatrix : WORLDVIEWPROJECTION < string Object = "Light"; > ;
//float4x4 LightViewProjMatrix : VIEWPROJECTION< string Object ="Light"; >;
//float3 LightDirection : DIRECTION < string Object = "Light"; >;
//ライト関連
bool LightEnables[MMM_LightCount] : LIGHTENABLES; // 有効フラグ
float4x4 LightWVPMatrices[MMM_LightCount] : LIGHTWVPMATRICES; // 座標変換行列
#define LightWorldViewProjMatrix LightWVPMatrices[0]
float3 LightDirections[MMM_LightCount] : LIGHTDIRECTIONS; // 方向
#define LightDirection LightDirections[0]
float3 LightPositions[MMM_LightCount] : LIGHTPOSITIONS; // ライト位置
float LightZFars[MMM_LightCount] : LIGHTZFARS; // ライトzFar値

// ライト色
//float3 LightDiffuse : DIFFUSE ;
//float3 LightAmbient : AMBIENT ;
//float3 LightSpecular : SPECULAR ;
// ライト色
float3 LightDiffuses[MMM_LightCount] : LIGHTDIFFUSECOLORS;
#define LightDiffuse LightDiffuses[0]
float3 LightAmbients[MMM_LightCount] : LIGHTAMBIENTCOLORS;
#define LightAmbient LightAmbients[0]
float3 LightSpeculars[MMM_LightCount] : LIGHTSPECULARCOLORS;
#define LightSpecular LightSpeculars[0]

//float3 MaterialToon : TOONCOLOR;
float4 MaterialToon : TOONCOLOR; // MMM独自

float EdgeWidth : EDGEWIDTH; // MMM独自

12932430 journal
日記

Ledの日記: ユーザー情報を更新した 2

日記 by Led

BowlRollで自分が配布しているもの一覧を見るアドレスを知らなかったので、リンクを貼っていなかった。でも最近これだとわかったので更新した。スラドのユーザー情報を見てる人ってどれ位いるかわからんけども。

ざっと見たところ、モデル崩壊エフェクトのDL数が他と比べてずっと多い。MMDer的にはこれは完全に「モデル崩壊エフェクトの人」ということになるだろうか。

12914382 journal
プログラミング

Ledの日記: CUDAやってみる

日記 by Led

まずは必要なものを揃えようってんで、Windows10の入ったマシンでCUDAプログラミングができるかどうかやってみる。

1. Visual Studio 2013 Express をMSから入手してインストールした
2. CUDA Toolkit 7.5をnVidiaから入手してインストールした

で、サンプルプログラムをコンパイルしようとする。具体的には

nvcc cudatest.cu

というコマンドをコマンドプロンプトで実行しようとするのだが。
環境変数Pathにcl.exeの入ったフォルダが含まれていないとエラーが出るので、
cl.exeを見つけてそのフォルダをPathに追加した。

で、nvcc cudatest.cuを実行しようとすると、さらにvcvars64.batというファイルが見つからないというエラーが出る。
どうしたものかと思ったが、cl.exeのフォルダ配下の x86_amd64というフォルダをコピーして、
amd64という名前にしてやったほか、その配下のvcvarsx86_amd64.batをリネームしてvcvars64.batにしてやった。

で、コンパイルはできた。コンパイル中は文字コード関連の警告がやたら沢山出るが、とりあえず無視。

a.exeというファイルが出力されて、無事に実行できた。

------------------

x86_amd64配下にはdllも入っていて、こいつらをコピーした状態で使うのはやや気味が悪い。
Windowsでもリンクくらい張れるので、リンクでちゃんと動くかやってみる。

------------------

コピーやリネームをする代わりにmklink コマンドを使ってシンボリックリンクを作ってもうまく動くようだ。
サンプルをコンパイルする程度には。

自分的にはこっちのほうが心が安らかである。

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...