たがやしいちろうさんの絵板２～なんでも～

石子先生のスクリプトをお借りしてFBX出力でネームスペース除去に着手。gameexporterはノード選択必須なので選択ノードからNSを取得する方式に。

いや、ほぼコピペだもの…すごいですっあざますっ！Twitterやめちゃったから直でお礼言えず申し訳ない限りっ。（以下変更分）

ちなみに該当関数だけmel化してローカルのスクリプトパスに移動するお手軽書き換え仕様に。

//------------------------------------------------------------------------------
/// @pre 足りない出力設定の追加
FBXExportIncludeChildren -v 1; /// @pre -> 子階層を含む

/// @todo 除去するネームスペース （選択ノード最後から取得）
string $NS = "";
string $NSList[] = stringArrayRemove({"UI", "shared"},`namespaceInfo -lon`);
string $selList[] = `ls -sl`;
if(size($selList)){
for ($node in $selList){
for ($namespace in $NSList){
string $matchname = $namespace + "*";
if(`gmatch $node $matchname`){
$NS = $namespace;
}
}
}
}

/// @note FBXExport用のフラグを fileコマンド用のフラグへ変換
string $mode = ("-s"==$exportSelectionFlag) ? "-es": "";

/// @note fileコマンド作成
string $cmd ="file -f -op\"v=0;\"";
$cmd +=("-rns \":"+$NS+"\" ");
$cmd +=("-typ \"FBX export\" "+$mode);
$cmd +=(" \""+$exportFilePath+"\"");

/// @post fileコマンドを使って出力
if( catch(`eval $cmd`) )
//------------------------------------------------------------------------------

退去に伴う掃除＆立ち合いから通信設備更新に伴う掃除＆立ち合いまで…この土日疲れました。

そして疲れすぎてまた例の症状が。立ち上がれない。飯屋に家人といって一口しか食べられずにヘロヘロになりながら帰る…循環器か消化器か。血圧がいつもより10%低下してるから循環器だろうとは思うけど医者は太り過ぎというだけなので恐らく何も問題はない。今日日の医者は初期の診察目的以外は追加での診察は一切してくれないので患者と医療の意識ギャップが偉い事になっている。というか高年齢になるほど早く死んだ方がいいという判断なんだろうなぁ。気になる症状があっても診察目的以外なので知識あって判っててもスルーするのが今の医療。仁道はどこにいったんだろうね？研修医・宿直制度などで命を削ってると思うけど、それ患者のせいではない医療運用の問題だがそのツケを患者がその命で払うのだ。困った国になったものだ。

通信設備切替のためこれまでの無線ルータが不要になっちゃっていきなり２つも要らない子に。10年位前？のやつで2.4G？対応。そして何故かuFooが5G対応してなくてそちらもイキナリ使えない子に。何か凄く勿体ないよなぁ。

週末も疲れがぬけない、強い倦怠感。
平日は普通に出社してて確かに倦怠感あるものの普通に動けるのだけどねぇ。屈伸的なふくらはぎの動きに伴う循環器的な何かが関係してそうな気もしつつ、休日でのおかしな食生活が関係してそうでもあり全く原因判らず。何度病院行っても原因判らないのでもう究明する気にならず。ただ強い倦怠感だけが残るだけ。多分今血液検査したら肝臓値が相当悪化してるのだろうなぁ。改善のために業務をかえてもらったというのに。ゆっくりしつつ規則正しい生活を。

スクリプト覚書

MELでarnoldRenderToTextureが実行可能。

https://forums.autodesk.com/t5/maya-shading-lighting-and/how-to-access-arnold-s-render-selection-to-texture-utility-with/td-p/6569468

https://discourse.techart.online/t/maya-export-file-node-adjustments-to-a-new-file/16011/6

ただディレクトリや数値を変数指定すると何故か上手く出力できないので一度文字列に直して変数($command)に組込み、それをeval($command);等で実行しないといけない。

また実行後に即AOシェーダーを削除すると結果が上手くいかない事があるので、削除もeval化しないといけない。

そういえば今更ながら、ついにマイナス金利脱却の報。
そして蓋を開ければ「はいはい、口だけ、ポーズだけ」と揶揄されるかのような一気の円安加速で日銀政府双方での介入圧力という最大プレス。清水の舞台からっというイキオイでドヤったのにワロスワロスとあしらわれて顔真っ赤にしてキーキーいってる国に機関投資家も冷笑。

でもその機関投資家もこぞってAIを機関車に一気にIT銘柄に唾つけまくったせいでもう天井超えそうで、やっとこさバリュー物色の流れにも。金の流れが一巡したとみるべきか。ただここから米金利順次切り下げで金の流れの潮向きが変わる際に株に流れるか唯一の金利切り上げの日国債に流れるかは…いや上がっても結局2%超えないから無いだろうな。潮が遅滞する時に世界情勢がどう変わるか？今年の夏から秋にかけて何か大きく動き出すのかもしれない。露華の鳴動と米大統領選と…こうしてカード見ると結構ヤバ目の潮目だったり。俺が死ぬまでは世界は泰然とあってほしい。

スクリプト覚書
mgearの設定ウィンドウが使い勝手悪い。オプションONで1ウィンドウのみでノード選択したら自動切替わる方式になってほしい
トグルボタンとscriptjob組み合わせたらいけそうな。ただあれwindowじゃないんだよなぁ。最近GUI弄れてないからまた０から探る必要あってそんな暇はないっ

今日は毎年一度の恒例事務作業完遂っ
がんばった！おれたん！

▷付加価値を考える

ゲーム開発において「付加価値」を考える事はマネタイズをどう選択するか？次第ではありますけど、要は「より高価」に「より多数」に行き渡らせる方法の模索とも言えます。

・パッケージで言う”ミリオン”（ほぼ固定開発費に対する売上本数）など「売上」で儲けを出す
　→全体の収支が読みやすく売上予測も比較的立てやすい

・ソシャゲで言う”イベント×ガチャ”（比較的安価な制作費でのリカーリング型の薄利多売）など「利鞘」で儲けを出す
　→開発費の内、初期支出は大きいが運営期に入って長く続けるほど総利益は大きくなる皮算用（ただし昔の話）

・動画／教育商材（広報等の販促ベースの売上）での「棚ぼた」で儲けを出す
　→初期費用は低いがランニングコストや販促など主業務以外での宣伝活動が大きく影響（突き詰めれば専門学校など）

▷生産性を考える

ゲーム開発において「生産性」を考える事は固定費（人件費）／開発費をどうするか？ですが、要は下限ボーダーラインの模索や生産力改善の模索とも言えます。

・固定費／開発費の削減
　→RPGツクール/ノベル系エンジン/TCG系エンジンなどアセット組み込みだけで制作できるジャンル選択するなど初期費用をお安くあげる
　→安い人件費でやれる事をやる（国際的に日本が一番人件費安くなって帝国主義的搾取は今は昔の話だし、費用対効果としていずれ内製回帰に）

・工数工程の最適化

・生産量の拡大

▷金額ではない利益を考える

「売上」「支出」という収支だけを見ていては中々思いつかないのですが収支に依らない「利益」もあります。
例えばブランド力向上が差別化・寡占化を促し業務をより円滑に持続継続させる事に大いに役立つものも「利益」となります。
例えばノウハウのナレッジ化による資産転化（教育商材など）やナレッジによる教育力や技術力向上だったり、過去成果物の商材化やAI活用なども「利益」といえます。

これらは「アイデア」で「付加価値」が生み出された一例とも言えます。
非商材や無価値だった無形財を有形有益の財源に転化する訳で、個人的にはこうした行為が本当の意味での「付加価値」だと思う訳です。

▷儲かる業務を考える

実は開発で一番難易度高いのはアイデアを実機でプレイできるようにする初期開発です。
初期開発は基本売上つかない上に支出でみても本番制作より基本安い。けどそもそも開発に予算ついたりＧＯサイン掛るようになるには初期開発は避けては通れない。
この初期開発は基本内製でしか行われず、専属で開発する会社ってのは聞いた事がないです。言わばニッチ。

その路線で連想すれば、例えばアイデアはインディーズや個人などから安価で買い取って初期開発後にそれこそＮ社などに試作というＩＰの卵を売り込みライセンスで儲けを得るというビジネススタイルも想像できます。
売り込み後はβ版開発~本開発とより規模を広げたプロジェクトとなりますが、それは別部署で行うなどでも良くて要は初期開発専属部門など。超ベテラン勢の集いなので実現性０ですがｗ
ただこれを生成AIなど活用して「素早さ」を売りにするなども考えつきます。

（つづき）
人間関係も業務進行もアレな中、早々にお声かけあって何故か自分が女傑チームのリーダーにとか云う話もあったりして本当に地獄のような開発だった。

脱線ながら仕事のアレさに加え家庭事情の泥沼で息が上手く吸えなくなったり長時間電車に乗れなかったりと心に強烈なダメージ受けて結局チームを離れる事になったりもしたんですよね…って結論いっちゃったｗ

ま、それは兎も角そこで作ってたものの話をみる事があって、そのプロジェクトも結局そもそもの理論に疑問が生まれたり精度が担保できなかったりしてペンディングになっちゃったのね。アレが上手く開発できてたらもしかしたら何か潮流が変わってたかもしれないと思うと勿体なくもアリ、同時に早々に見切りをつけれて良かったとも。

個人的には心身的にもその後のキャリアパスにも相当にダメージを受けて今の素地を生み出す一端にもなったと思うんだけど…ま、それはそれｗ
てかもっと自分がオシャレさんでセンスあふれる人間だったらスマホの無い当時でも大きな何かが生み出せたんだろうか？いや、結局時代の徒花みたいなものにしかならんかったろうね。

今でもあの当時の知見は定期通院時の血圧測定に生きています。高血圧まっしぐらだけどｗｗｗ結果がついてきてないｗｗｗ

通信とかはどないなん？スマホ価格転嫁とかこの10年無制限に進めすぎて流石に天井ついてね？厳しいか…いや全くあたらしいデバイス普及とかイミフムーブあればあるいは？つかAppleWatchなんか米国内でサブマリン？よく知らないけど特許絡みで発売停止追い込まれて未だに身動きつかない中でVR投入とかもう手札擦り減って業界的に末期にも見えたり見えなかったり。スマホ登場から16、7年…そりゃ製品サイクルの場末だもんね。インフラの中心になったから無くなりゃしないけど経済の牽引役ではなくなりそう。個人端末的にはデバイスとか飛び越えて網膜やら脳波で直接個体にアクセスできるようになるまでは恐らく大きな変化は見えないか？それまでにワンチャンあるとしたら個人端末以外の社会・コミュニティインフラ面くらいか？

金融はダメぽ？いや、金融はマジで地雷か…長引くなら引き際要注意で可能性は無くはない？…危険すぎるけど。日銀1%2%とか細かく区切らずいっそすっぱり5%とかやってくれりゃ国内銘柄は一気に目が出るのに。経団連とかその辺りの政治駆け引きで新型NISAとかでチマチマ周辺潤してそうとかセコイ金融政策ばっかやってるからダメな国よね。

コモディティとは違うけど、化学はどうなんだろ？メーカー系は基本インフレでは割を食う側だから弱い側だろうけど、SDGsは一過性の流行だとしても温暖化被害が一服しない限りは燃料・原料・素材・エネルギー転化は必須なので別の側面からみてやっぱり化学系の工業量産化は宝くじよりも確率高めで狙えるとも。

社会・コミュニティインフラと書いててフト思うのは「公共でのＡＩ」。AIいうても今をトキメク特化型の話だけどね。

AIをぶん回すにはハードウェアなり電力なりリソースを大量に要するし、リアルタイムなんて事になると現段階では更にコストがかさむ。まぁ個人でエロAI画像作るとかなら大したことはないけど、今の傾向を支えてるのはマイニングで消費されてたものをAIで消費するガワのツールが変わったくらいなのかなぁとか無知者の認識。そりゃ個人レベルで想定してちゃ全くの見当違いだよ…どんだけマイニングで大量にハードもエネルギーも投資したと思ってるのやら。ま、それは違う話か。

云いたいのは現状のAIは個人ではなく公共である程度のリソース担保して初めて生きるかなと。ここで最初の「公共インフラとしてのＡＩ」に結び付く。

これ、なんか以前にも同じようなことを…と思ったら既にアカ消したTwitterで呟いてたｗ「公共（自治体や沿線主導での）蓄電池網」だった。…いや、同じじゃないけどパターン（根っこ）は同じかなと。

公共wi-fiの急速な普及による外部での動画視聴などスマホ利用の一層の普及を見ても公共（的）なインフラ環境の充実は利用を一気に加速させ新規サービスの展開にも繋がる。

まだ国内のAI活用はスタートアップベースが始まろうとしてる段階。ぶっちゃけサービス内容も「仕事で安心できるChatGPT」みたいな印象を受ける。後追い臭半端ない。そうじゃなくもっと大枠というか視点を変えて考えなきゃ先行産業は生まれないよね。

はよ寝なきゃ…

先日超久々に浴槽はいったら湯あたりして階段のぼれないほど強烈な倦怠感と血圧低下が。いわゆるヒートショック、心臓だよなぁ…いやだね。

兎にも角にも会社にも相当迷惑かけてるので何とかこの数ヶ月で体調を取り戻したく候

FOVが実は「長さ」ではなく「角度」だという認識が日本では結構主流らしい。いやUnityとかN社開発環境もfovyは角度だから恐らく業界的にはそれが一般理解ぽい。
でも自分がこちらの資料を作成するにあたってあたった英語圏の資料だと「長さ」がメインだった。これはどこで何が絡まってこうなったんだろう？
ちなみに国内のブログなり情報まとめをみるとFOV＝AOVなんてのも結構普通に言われてる。
まぁUnityで言えば確かにFOVとAOVは全く同じものになる気がする。

とはいえ実のところFOVとAOVは厳密には異なる。AOVはレンズから被写体までの区間での「画角」だがFOVはセンサーからレンズを通して被写体までの「視野角」となる。同じじゃない？とおもうのだがどうもAOVに比べFOVは角度が若干狭まる＆フォーカルレングスも長くなるようだ。…多分。

なんにせよこの辺りをちゃんと説明してくれる情報源が欲しい。

いや、でも当のUnityのリファレンスですらFOVが長さとして図示されてたりするんで多分誰も長さか角度かなんてあんまし気にしてないのではなかろうか

車のメッシュグリルがいれたいんだよなぁ

何も考えず最新のに替えたらどうやらxfreeではphpバージョンが7.1までしか対応してなくて急遽ロールバック。

恐らく最新としては3.19.5が安定板なのだろうけど、大きなバグ修正もなさそうなのでサーバのphpバージョンアップ待ち（という名の不精ｗ）ということでお許しを