Maya Script Pymel UVシェルのアイランド数を数える

from pymel.core import *

sel = selected()

print sel[0].getUvShellsIds()[1]

下らないものですが、こんなものを作りました。
オブジェクトを選択し、上記のスクリプトを実行すると、そのオブジェクトのカレントUVに含まれるUVシェルのアイランド数を数えられます。

 

同じ効用のあるスクリプトをwebで発見しました。
それはOpenMayaを使って書かれており、自分には真似できない代物でした。
Pymelではどのようにやるのだろう。とリファレンスを見ていると、同じコマンドがあったので試しに使って見ました。
あまりにも簡単に出来てしまうので、驚きました。

 

何に使うのか、と言われても困りますが、驚いたので載せました。
他にもコマンドを見てみると、色々とあるのでもっと面白い事もできそうです。
Pymelのコマンド表はmelやPythonのものと違い、特殊な形態です。とても使いにくい、、
せめて例でも載せてくれると、自分のような中途半端な知識のものでも気軽に使えるのですが、、
しかしPymel、凄いですねぇ。これは実はとてつもない破壊力を持ったツールなのではないでしょうか?
もっと情報が豊富に有れば良いのですが、まだ出来立ての物の用で、情報が少ないのが玉にキズです。

追記どうやら出力するだけなら一行だけで良いようです。

from pymel.core import *

print selected()[0].getUvShellsIds()[1]

雑記83 – 「構造デザイン講義」

建築の本です。
養老孟司さんが新聞で書評を書かれていたので、読みました。
書評の内容は覚えていなかったのですが、読み進めてしばらくして一部思い出しました。

 

うろ覚えですが、
講義の内容を本にした、という形態なので仕方が無いのだろうが、(笑)が多い。
冗談を言う時は(笑)を付けないと冗談であると受け入れてもらえない世の中になったのだろう。(笑)
というような内容でした。読んでいて思わず吹き出したことを思い出しました。

 

それはともかく、内容は現場で散々やられていた方が書いたもので、養老さんも仰っておりましたが、
とても現場で来て、身体的なものとなっております。建築に興味がなくても面白い。
組積造と呼ばれる西洋建築の大本の石を組んで行う土木建築の説明から始まり、現代のコンクリートとスティールで行われる建築へと時代を追って解説されております。
ご自身、長らくそういった建築に関わって来たようで、内容が現場的で大変興味深く読ませて頂きました。

 

コンクリート一つをとっても、時代を経るに従い、現場で人が捏ねるという工程から、ミキサー車での大量生産に移り、
低価格が実現されていったそうですが、質は明らかに落ちていったそうです。なんだかよく聞く話です。
そして、工場でブロックを作るプレキャスト、と呼ばれる手法が出てきたことにより、品質は良いが、設計がきちんとしていないと難しい工法などもできたそうです。

 

解析についても書かれております。
建物の強度計算です。一昔前まで人が何度も計算を行い確認していたものが、現在ではコンピュータによって行われるそうで、
それにより、遥かに大量の解析が可能になったそうです。しかしコンクリートと同じように質が落ちたことは偽装問題によって明らかになりました。

 

書籍の半分以上をこういった現場レベルでの話を交え、歴史を交え建築というものについて語られておりますが、
最後に木造建築について、語られております。
そして、今まで説明された西洋建築を「無矛盾系」と定義し、それは整合性の高い構造体の中に1個の矛盾があると、あらゆる外力がその矛盾一点にかかり壊れる危険性がある。
それに対して、木造建築というのを「多矛盾系」とし、各ジョイントに矛盾があることで構造体として強くなる。と説明されております。
阪神淡路大震災では、多くの木造建築が倒壊したことが報道されましたが、どうやらそれらは店舗型の木造住宅だったようで、間口を広くとり、耐震設計の弱いものだったそうです。
そして、地震にも個性があり、鉄筋コンクリートであっても、むしろ鉄筋コンクリートであるから、そういった個性に対応できずに倒壊している事実を説明されております。

 

以前、建築をやっている方に聞いた話を思い出しました。
日本の建築技術はとても優れているそうですが、現代においては、各部屋に蛍光灯があるのが当たり前で、エアコンがあるのが当たり前。という事が前提になっている。
本来建築というものは地域の特性、採光、換気、様々な条件に合わせて作っていた。自分は何を作っているのか分からなくなった。
と、仰っておりました。
そして、この本の著者も現場の空洞化を指摘しております。
コンピュータ任せ、極端な画一化により、現場で柔軟に動ける人が少なくなっているそうです。うーん、なんだか今っぽい。

 

また、個人的に興味深かった点は、イギリスのミレニアム・ブリッジについて書かれていたところです。
この橋はイギリスが威信を懸けて作ったものでしたが、開通式当日、両岸から人が橋を渡り始めるてしばらくすると、橋が大きく左右に揺れ始めました。
もちろん解析は行なっていたそうですが、橋は封鎖され原因の究明が始まりました。
そして、毎秒1回の定期的な横揺れに対して弱いことが分かったそうです。毎秒1回といえば、人の歩みがそれに相当します。
人が歩く時に発生する微量な外向きの力が橋を伝って増幅し、最終的には橋全体を蛇のように大きく揺らせる原因になったそうです。要するに同期現象です。
この本の著者は見るからに強度が足りていないことを指摘されております。流石です。
デザインを重視するあまりに強度を軽視した結果のようです。

 

多矛盾系、いい言葉ですね。とても気に入りました。日本っぽいです。
理屈は分からないけど、それでいい。大したものです。

MayaScript Pymel バンプノードに張られたテクスチャの確認

from pymel.core import *

for x in ls( mat=1):
	if x not in ["lambert1","particleCloud1","shaderGlow1"] :
		if x.normalCamera.inputs() :
			x.normalCamera.inputs()[0].inputs()[0].outColor >> x.color

バンプノードに張られたテクスチャをカラーに張り替えるだけのスクリプトです。
元には戻らないので、シーンを保存してから実行し、そのシーンは保存しないでください。

 

色々なページを参考にしながら、ああでもない、こうでもない。と試行錯誤を繰り返しました。
pymelの日本語の情報はかなり少ないようです。
しかし数行で書けてしまったので、驚きました。
もっと短くするなら4行目は削除しても良いかと思います。
4行目で排除しているものは、Mayaのデフォルトでシーンに設定されているマテリアルなので、
一応作法的な感じで入れているだけです。
そもそも、それらのノードにアクセスするはずもない。というのであれば削除して以下の行のインデントを一つ削れば動きます。

 

とても稚拙なものですが、役に立つようであれば使ってやってください。

MayaScript Python 不正なスキニングウェイトの検出

import maya.cmds as cmds
import maya.mel

def CheckWeight():
	oErr = ""
	oRes = ""
	oSel = cmds.ls( selection=True )
	oShp = oSel[0]
	oFlg = 0
	oVcount = cmds.polyEvaluate( oShp, v=True )
	oSelv = []
	oSkt = "findRelatedSkinCluster " + oShp + ";"
	oCls = maya.mel.eval( oSkt )
	oMxc = cmds.getAttr( oCls+".maxInfluences" )
	oVtx = cmds.ls( oShp + ".vtx[*]", fl=True )

	for v in oVtx :
		oWei = cmds.skinPercent( oCls, v ,query=True, value=True )
		while 0.0 in oWei: oWei.remove(0.0)
		if len( oWei ) > oMxc :
			oFlg = 1
			oSelv.append(v)
			oErr = oErr + str(v) + u" インフルエンスが " + str(oMxc) + u" を超えています" + "\n"
			oRes = oRes + str(v) + u" インフルエンスが " + str(oMxc) + u" を超えています" + "\n"
		oWes = sum(oWei)
		if "%.2f"%oWes != "1.00" :
			oFlg = 1
			oSelv.append(v)
			oErr = oErr + str(v) + u" 合計が1ではありません [" + str(oWes) + "]\n"
			oRes = oRes + str(v) + u" 合計が1ではありません [" + str(oWes) + "]\n"

	if oFlg == 1:
		cmds.select( oSelv, r=1 )
		if len(oSelv) > 1 :
			for v in oSelv :
				cmds.select( v, add=1 )
	if oErr == "" :
		oErr = oErr + u"エラーは見つかりませんでした"+ "\n"
	cmds.confirmDialog( title=u'エラー', message=oErr, button=['Yes'], defaultButton='Yes' )
	print "result-------------------------------------------------------"
	print oRes
	print "-------------------------------------------------------------"
CheckWeight()

前回はスキニングウェイトの四捨五入を紹介しましたが、それだけだと実際にできているか分からないので、それを調査するスクリプトです。
オブジェクトを選択し、スクリプトを実行してください。

 
因みに、直接シェルフに登録する場合は、
4行目を全て削除し、それ以下の行すべてのインデント(段落)を1つずつ削除してください。
Pythonはインデントをきちんと見ているので、インデントがずれていると作動しません。
その状態で、シェルフに中ボタンドラッグをすればファイルに保存しなくても使えます。
Mayaのスクリプトエディタは、Pythonを書くのに適していないのか、スクリプトエディタでPythonの編集を行うと、良くエラーになります。
恐らくインデントが関係しているものだと思います。
大抵テキストエディタで編集して、コピペしています。

 

このスクリプトで検出する精度を変更する時は、18行目「5」の値を少なくしてゆくと精度が高まります。
後は、23行目の「%.3f」の値を変更すると合計値の精度が変えられます。

実行すると、何も問題が無ければ何も起こりません。不親切設計です。
必要があれば、ダイアログの表示やプログレスバーを追加してください。プログレスバーは前回のスクリプトからコピペすれば使えます。
問題がある場合は、その頂点を選択しスクリプトは終了します。
必要があればコンポーネントエディタなどを使い手動で調整してください。
問題の検出は、小数点以下4桁以上の値が入っている頂点。
合計して1になっていない頂点です。

 

最終的な環境にもよりますが、ゲームエンジンで使用されるデータとしてエクスポートする時に四捨五入される場合もあります。
そのデータがアスキーデータであれば、直接テキストエディタで開いて編集してしまうのも手かも知れません。

 

自分はMayaでウェイトを設定する際は、こちらのツールを使っています。
古いツールで、しかも書かれいてる機能が動作しない箇所もあります。それらの機能を使うには改造が必要です。
XSIのような感覚でウェイトを調整できます。ただ、選択した頂点全ての値が表示されるわけではなく、複数頂点を選択するとその平均値であることがちょっと難点でしょうか。

 

どうやらウェイトに関してはアバウトな部分があるようで、
色々と計算を考えたのですが、設定されている値を見て合計値が1になるように設定する方法は自分には分かりませんでした。
しかしコンポーネントエディタで桁数を変更すると勝手に良い具合に四捨五入されます。
どうやら数値が細かくなればなるほど合計の値は1に近づくので(当然ですが)、コンポーネントエディタではそのせめぎあいを勝手にしてくれているようです。
スクリプトで取得する値はそのせめぎあいが無い値が表示されます。
だから桁数を多めにして四捨五入すると程良くなり、ぎりぎりで四捨五入すると1から大きく外れてゆくのだと思います。
色々と勉強になりました。
ああ、そうだ、勉強ついでにこれをpymelに翻訳してみようか。などと考えてしまいました。

 

追記と修正2011/12/10
四捨五入ツールを修正しながらこちらを使ってみようと、中身を開いてびっくりしました、、
一体何を見て検出しているのやら、、うーんこっ恥ずかしい。
お詫ついでにエラー処理を加えておきました。
あれ、急いで更新したので、記事の内容を読んでいませんでしたが、細かい数値のウェイトを見るようにしていたのですね、、
ああ、それだったら良かったのかな?
新たなものでは、四捨五入はされることを前提に、インフルエンスの数を超えている頂点をチェック、合計が1にならない頂点をチェックです。

MayaScript Pythonでスキニングウェイトの四捨五入

RoundWeight

import maya.cmds as cmds
import maya.mel

def RoundWeight():
	oSel = cmds.ls( selection=True )
	oShp = oSel[0]

	gMainProgressBar = maya.mel.eval( '$tmp = $gMainProgressBar' );
	oVcount = cmds.polyEvaluate( oShp, v=True )

	oSkt = "findRelatedSkinCluster " + oShp + ";"
	oCls = maya.mel.eval( oSkt )
	cmds.setAttr( oCls + ".normalizeWeights", 0 )
	oVtx = cmds.ls( oShp + ".vtx[*]", fl=True )
	cmds.progressBar( gMainProgressBar, edit=True,beginProgress=True, status='Now Rounding...', maxValue=oVcount )

	for v in range( len( oVtx ) ) :
		oW2 = []
		oWei = cmds.skinPercent( oCls, oVtx[v], ib=0 ,query=True, value=True )
		oJnt = cmds.skinPercent( oCls, oVtx[v], ib=0 ,query=True, transform=None )
		for w in oWei :
			oW2.append( float( '%.3f' %w ) )
		oLst = zip( oJnt, oW2 )
		cmds.skinPercent( oCls, oVtx[v], nrm=False, pruneWeights=0.009, transformValue=( oLst ) )
		cmds.progressBar( gMainProgressBar, edit=True, step=1 )
	cmds.setAttr( oCls + ".normalizeWeights", 1 )
	cmds.progressBar( gMainProgressBar, edit=True, endProgress=True )

紆余曲折、色々とやって見ましたが、最終的にこんな感じになりました。
これでいいのか分かりません。幾つかのモデルでテストして見ましたが、一応できているようです。
ただ、完璧にできないモデルもあるようなので、ご注意ください。
毎度のことですが、権利も責任も放棄します。勝手に改良してください。

 

このスクリプトで、実際にウェイトを丸めている部分は22行目です。
たったそれだけです。
fpformat、Decimal、roundと色々なものを試して見ましたが、結局ただの置き換えで済ませました。
今回分かったことは、四捨五入の時に、小数点以下二桁までの値が欲しい時は、三桁の値まで丸める必要がある。
ということでした。
このスクリプトで丸めても、スクリプトを使ってウェイトの値を取得すると、細かい値を取得できます。
恐らくどんなスクリプトを使っても出てきてしまうかと思います。
コンポーネントエディタで値を取得すると、15桁までしか表示されないので、それ以下の値が表示されないだけのようです。
思えばライトウェーブは0%から100%の整数でウェイトの設定をしておりました。
確かに細かい値は入力できませんが、ゲームではそのくらいで十分です。ゲームCGに対するライトウェーブの優位性を身をもって理解しました。

 

melでウェイトの丸めツールを公開している方もいらっしゃいますが、Maya2011ではskinPercentのフラグが追加され、
聞いた話ではウェイトのノーマライズも頂点単位からオブジェクト単位に変更されたようで、そのままでは使用できません。それらに手を加えると使用できるようになります。

 

因みにこのスクリプトの使用方法は、スクリプトをC:\Users\ ( USER ) \Documents\maya\scripts\に入れて
Mayaのスクリプトエディタを開き、入力タブを「Python」に変更し、

import RoundWeight
RoundWeight.RoundWeight()

と入力し、そのコマンドを全選択し、中ボタンドラッグでシェルフに登録するとアクセスできるようになります。
使用時は、オブジェクトを選択し、シェルフに登録した物をクリックしてください。

 

ついでに、このスクリプトでの丸めの計算の前に、幾つか計算を足すと更に精度が上がることが確認できました。
しかし、そこまでの精度を求めても仕方が無いし、その計算は自分が考えたものではないので付けるのをやめました。あしからず。

 

ところで、久しぶりにZBrushを触りました。
久しぶりだったので、感が鈍っていました。ツールの使い方は問題ないのですが、
形の作りが甘すぎる。やっていないので当たり前ですが、ちょっとショックです。
スクリプトばかりやっていないで、またZBrushを勉強し直そう。

雑記82

うーん、浮動小数点と戦っております。
なるほどねぇ、今まで知識としてはあったものがようやく体感できた感じです。
うまく行ったかと思ったら、やっぱりダメだった、、

 

小数点以下の数値を四捨五入するため、桁を上げて
浮動小数点を文字列に変換したりもして見ましたが、再び浮動小数点に戻すと細かい数字が出てくる。
小数点の位置をずらすだけで良いんだよ、と声を掛けたくなりますが、人間のようにそんなビジュアル的な話は機械に通用しない。
Pythonに実装されている幾つかの関数を使ってみたりしても、やはりちょっとした不具合が出てしまう。難しいなぁ、、

 

そういえば、Mayaはそこそこ日本のゲーム会社で使われているツールかと思いますが、
なぜこれほど単純で必須な機能がないのだろうか?と疑問になります。
恐らくインハウスのツールがデフォルトの様に大きな会社であればどこでも入っているのだろうと思う。
小さい会社はどうしているのだろうか?最近はそういった会社の人と交流が無いので分からない。
今度機会があったら聞いてみよう。

 

XSIでは一応桁数が制限されています。
しかし、FBXで吐き出すとやはり細かい数値が入っているのを昔確認しました。
吐き出す時についてしまったのか、XSIが内部的に持っているものをただ出していないのか分かりません。
どちらにしても映像関係の仕事では全くといっていいほど関係ないことかと思います。
ゲームCGでは仕事の8割くらいはデータの整理に当てられているように思います。
ゴミを少なくし、データ量を抑える。ということに時間を割きます。
そもそも作っているものがゴミだ。と言われてしまうと立つ瀬を失います。

 

ああ、そういえば文字列の操作で思い出したことがあります。
遺伝子の話です。
遺伝子は、チミン、アデニン、シトシン、グアニンの4つの塩基で構成されています。その4つが法則により配列され情報となります。
そして、分子生物学者は、まず操作したい遺伝子の塩基を全て調べることから始めます。そして、どの塩基がどのタンパク質の生成に関わっているのかを調べます。
プログラムでは自分で勝手に作ったり、引き出してきた文字列を手軽に扱えますが、生きているものを相手にしていると、最初に文字列を取得するだけで時間がかかります。
そして、目的の文字列が判明すると、次にその文字列を操作することになります。
人工的に作ったmRNAを生成し、文字列を分断するそうです。
プログラムでは簡単に出来てしまう工程も、同じ事をしていても分野が違うと全く別の作業になります。
mRNAの純度の高さを保つには、職人のような勘と経験が必要だそうです。それはそれで面白そうだ。
文字列を操っていると、ついついそんな事を考えてしまいます。

雑記81 – 「ごく平凡な記憶力の私が1年で全米記憶力チャンピオンになれた理由」

 
どこかで竹内薫さんが書評を書かれたのを見たので、読んで見ました。
とても面白い。
書き出しは、決勝戦の様子から始まり、その後経緯の説明になる。という映画的な手法を取られております。

 

著者はフリージャーナリストで、全米記憶力競技の取材をしていたところ、興味を抱き誘われるがまま参加することになったようです。
そして、人間の記憶というものを、歴史的、脳科学的に取材を進めると共に、古代ギリシア発祥の記憶術をマスターしてゆきます。
初めの方では、記憶を完全に固定されているもの、といった解釈だったようですが、それらが次第にあやふやなものである、という事が判明してゆきます。
そしてついには、「私たち西洋人は「自己」、つまり自分という人間の核のようなものについて、あたかもそれがはっきりと区切られている実体であるかのように考える傾向がある。」
というところまでたどり着きます。
どうもそれは今では西洋人だけではなく現代人全体に言えることなのだろうと思います。
そして、それに対しての疑問が出てきているのも現代的なものなのかとも思います。

 

著者が初めて記憶術を教わる時に、コーチが今度のパーティーで必要なもの、という心底どうでもいい情報を記憶させられます。
そして、それが著者の脳に刻まれてゆくと共に、読者である自分の脳にも刻まれてゆきます。
あまりにもどうでもいい情報が面白いくらいに覚えられてしまうので、思わず読んでいて笑ってしまいました。
なるほど、これは脳の生理をよく理解している。
昔の人達はどれだけ記憶、というものを大切にしたか、そして現代に生きる我々はそれをアウトソーシングしている。
どちらが優れている。という問題でもありません。実際にその記憶術を体得しても普段の生活いおいて、大きく役に立つわけではありませんん。
しかし、それを体得する。ということはそれだけで意義がある。
やってどうなる。という話ではなく、まずやってみろ。それから考えれば良い。養老孟司さんが良く言う言葉です。

 

ところで、今PythonでMayaのスキニングウェイトの数値を丸めるツールを作っております。
ある程度はうまくいっているようですが、やはり場合によっては細かい値が残っている。
それを調べていると、どうやらハード的な原因も含まれている、コンピュータであるかぎりは仕方のないことのようです。
面白い。結局近似なのですね。どこで折り合いを付けるか、どこで妥協するか。現実と同じです。

雑記80 – 確率の問題

どうも最近、以前は一部の人達しか関係の無かった確率の問題が身近なものになっていることを感じております。
量子力学ではコペンハーゲン解釈を得ることで、ミクロとマクロは関係しない。という結論に達しました。
放射性同位体が確率的に放射線を放出することと、ガイガーカウンターがそれを検知する過程では、すでに検出された段階でマクロな現象となり、
そのマクロな現象下に存在するものが受ける影響とは関係がない。ということです。

 

上記のことが分からなくても問題はありません。
恐らく、当事者もよく分からないから、それは関係ないんじゃない。ということでそうなったのだろうと思います。
しかし、現実世界には相転移、という現象が存在します。
これは、水が0度を下回ると凍ったり、100度を超えると蒸発したりする現象を指します。
そして、鉄が磁気を帯びたり、絶対零度付近で物質が超電導になる事も同じ現象です。
これらの現象は個々の分子の持つ運動の対称性を自ら破り、周りに同期して起きる現象です。
磁気で言うと、それまでバラバラな磁気モーメントを持つ鉄の分子が、磁石を近づけることにより、その磁気モーメントの方向性が大体揃い、
そのミクロな現象が鉄が磁気を帯びる。というマクロな現象になって表れます。
どうやら、人目が気になるのは人間だけではないようです。

 

さて、確率の問題です。
原発事故により、死の灰というものが、以前は漫画の中だけの話だったものが、我々の身近なものになりました。
これにより我々はどういった影響をうけるのでしょうか?
現状言えることは、やはりコペンハーゲン解釈と同じで、良く分からない。だと思います。
もちろん、だからといって無理に被曝することも無いかと思います。
放射線が我々生命に対して大きく有害であったから、それを遮蔽する大気が出来る以前は生命は栄えませんでした。
そして、大きく被曝した人たちが辿った運命も知ることが出来ます。

 

しかし、ここは一つ、人が生きる。という点に絞って考えてみたいと思います。
確率の問題で言うと、生きている人が明日死ぬ確率は50%です。以前天気について書きましたが同じ事です。
生きている状態、死んでいる状態という2つに分けるのであれば、明日どちらの状態であるか、という確率は50%です。
さらに今風に言い換えると、大抵の場合99.9%と言っても過言ではないかと思います。
要するに99.9%とは50%でもあり、0.1%でもある。ただし、0.1%である確率は99.9%無い。ここまで行くともはや意味が分からない。

 

それについて、古代ギリシャの哲学者、エピキュリズム(快楽主義)で知られる、エピキュロスがこんな事を言っております。
「生者にとって生きている限り、死とは現に存ぜず、死者にとって死とはすでに存ぜず。その認識が可死的な生を帰って楽しいものとしてくれる。」
要するに、生きている限り死んでいないし、死んだらそれは過去なんだから考えても仕方ないんじゃない?という事だと思います。
そして、彼が快楽主義と言われる所以は、
「苦しみが取り除かれること、これが快の量の限度で、それ以上は増大すること無く、快の質が多様化するだけだ。」
ということです。快楽主義、という語感から随分離れている。しかし、快楽という言葉を分解して考えると納得できる。
彼は膨大な著書を残したそうですが、現存するものは殆どありません。幾つか面白い言葉があるので、書いてみます。
「君が途方にくれて困っている限りは、それは君が自然(自分の体)を忘却しているからである。というのは、君は自分でわざわざ不確定な恐怖と欲望を作り出しているのだから。」
「万物は必然によって生じる。と主張する人は、そうでないと主張する人を非難することはできない。前者の主張では、後者の主張それ自身が、必然によって生じているはずだから。」
「僅かなもので十分と思わない人、少なくともこのような人には、十分なものは存じない。自己充足はあらゆる富のうち最大のものである。」
「明日を最も必要としないものが、最も快く明日に立ち向かう。」
うーん、二千年以上も前に、随分と書いてくれます。読んでいて楽しかったです。
また、彼は人生において、哲学こそが至上のものである。という信念に生きていました。
弟子に送った手紙の中では、羊飼いに一頭の羊を貰い、その御礼として哲学を教えた。と書いてあります。
勝手な想像ですが、その羊飼いの困った表情を想像してしまいました。

 

古代ギリシャの哲学者と、中世の哲学者では色々な面において、質が違うことが分かります。
しかし、一点全く変わらないところも存在します。それは、魂という明確に変わらない物を定義している点だと思います。
体というハードウェアと魂というソフトウェアが存在している。現代風に言うと、そのような事が言えるかと思います。
そして、現在の脳科学が直面している事実は、それらはお互い関連している。という事です。
人格が違うのは、ソフトの問題だけではない。ニューロンが作る、セルアセンブリ(細胞集成体)という要素が深く関わる。

 

大分話がそれました。
どうも最近の政治家の議論を聞いていると、損得勘定だけで話が進められているように思います。
政治の問題も同じ事で、明日のことは分からない。やってみなければ分からない。ということだけが明確に言えることです。
そもそも、政治家になって世の中が変えられる。とか、そういった人達に一票投ずることで世の中が変わる。などといった絵空事を頭から信じていないので、自分が理解出来ないのも当然です。
今の政治が大変であることは想像できます。メディアが発達し、直ぐにそれらが編集されて流されます。恐らく意図しない形で。
しかし、今の政治、経済の状況というのはどうなのでしょうか?
自分は遅れて地デジに対応したので、その境目を見ることが出来ました。今まで普通に映っていた映像が砂嵐になります。
新たに配線をしてもらうことで、再びテレビが見られるようになりました。しかし、ブラン管テレビはいずれ捨てなければいけません。テレビを見るためには。
まだ物理的には使えるものを捨てなければならないのに、子供たちにどうやって勿体無い。という概念を教えればいいのでしょうか?
思えば、日本は民主主義社会と言われていますが、少なくとも自分は地デジに賛成した覚えはありません。
ここまでインターネットが発達した世の中でテレビに画質や双方向の通信を求める人はそんなに多いのでしょうか?
そういった疑問は、スカイツリーは日本の技術の結晶である。という言葉でもみ消されたようです。

 

そういえば、以前ヨーロッパで核廃棄物についての話し合いが行われました。
そこでは、廃棄物処理場をどうするか?という事が話し合われたようです。数万年後、我々の子孫に当たる人々がそれを見つけた時、目印となるものがあると、掘り返そうとするのではないか?
という事を真面目に話し合ったようです。
そんな先のことを気にするのがバカなのか、そんな先のことを気にしなければならないものを使っているのがバカなのか。ここまで来ると良く分からない。
原発推進派の人たちが言う、発展に欠かせないもの。というのはそういった事を度外視しています。
24時間電力を使い冷やし続ける必要があり、増えることはあっても減ることはない。それだけとっても馬鹿馬鹿しいものであることが分かるかと思います。

 

しかしそれと同時に、自分もそうですが、こういった形で小さな発信が多くなる。
それが良いのか悪いのか、それは人それぞれの価値観で、そうなっちゃう。というのが本当のところなのではないでしょうか。
自然はしばしば増殖する。それは仕方がない。
まぁ、いっか。と、詰まらない落ちを付けてみます。

イラディアンスキャッシュを三倍にしてレンダリング

以前途中まで書いたスクリプトを修正したので、公開します。

#python

import os

file = lx.eval('query sceneservice scene.file ? current')
file, ext = os.path.splitext(file)
cache = os.path.join(file+'.lxi')
zfile = os.path.isfile(cache)
if zfile == 1:
	os.remove(cache)


for x in range(lx.eval ('query sceneservice polyRender.N ?')):
	id = lx.eval('query sceneservice polyRender.ID ? %s' % x)
	lx.eval('select.item %s set' % id)
	lx.eval('render.res 0 ?*3.0')
	lx.eval('render.res 1 ?*3.0')
	lx.eval('item.channel polyRender$irrSEnable true')
	lx.eval('item.channel polyRender$irrSName {%s}' % cache)
	lx.eval('render  options:4')
	lx.eval('item.channel polyRender$irrSEnable false')
	lx.eval('render.res 0 ?/3.0')
	lx.eval('render.res 1 ?/3.0')
	lx.eval('item.channel polyRender$irrLEnable true')
	lx.eval('item.channel polyRender$irrLName {%s}' % cache)
	lx.eval('render')

実行するとシーンが保存されているディレクトリにixi(イラディアンスキャッシュファイル)を探しにゆき、
存在すればそれを削除します。無ければ新たに作成します。
レンダリングサイズを一時的に3倍にし、キャッシュファイルを生成します。
レンダリングサイズを元の大きさに戻して、レンダリングを実行します。

 

次回からは普通にレンダリングすると、イラディアンスキャッシュが読み込まれます。
もう一度キャッシュを作りたい時はスクリプトを実行します。
コピペでテキストエディタに貼り付けて、拡張子「py」で保存し、
C:\Users\(ユーザディレクトリ)\AppData\Roaming\Luxology\Scripts\
に入れて、@ファイル名.pyでスクリプトを実行できます。

 

しかし、modoのスクリプトでは、スクリプト内でいちいちノードを選択しないと、設定が変更できない。
データを作成し流しこむように設定ができるともっと楽になるのになぁ、、
マテリアルの設定をスクリプトで変更するとシェーダーツリーでマテリアルマスクが開かれてしまう。
マテリアルが膨大な量になると閉じるのが大変だ。何かもっとスマートな方法は無いだろうか。

 

そういえば、前回の記事でレンダリングがうまく行かない、というような事を書きましたが、
イラディアンスキャッシュのせいでした。ロードのチェックが入っており、随分と古いキャッシュを参照していたようです。
チェックを外したらうまく行きました。
うまく行ったが、レンダリングはどうしても思うようにはならない、、やっぱり外観のレンダリングは難しい。

アニメーションが親切に解説されております

レンダリング、ライティングの基本が分かります

図版が見やすい美術解剖書です