PyScripter

PyScripterというものを見つけました。
Pythonの本を買ってちょっと本格的に勉強しようと思ったら、その本で紹介されておりました。

 

どこかで見た名前だ。と思っていたら、modomodeのTakumiさんが既に紹介されておりました。
当時は、自分にとっては縁のない高度なものだろう。と決めつけておりましたが、なるほどPythonを組むにはとても便利そうです。
プロンプトを使わないでもPyScripterからデバッグができます。
ただ、純粋にエディタとなると、やはりサクラエディタの方が軽快で、自分には向いているようです。

 

そういえば、3Dcoatがキャンペーン中で、2万円しない値段で買うことができます。
ZBrushを買おうとお金を貯めておりましたが、どうも3Dcoatを買ってしまいそうです、、
ペイント機能、ダイナミックサブディビジョン、リトポにUV編集、色々と使ってみたい機能がもりだくさんです。

 

スクリプトに3Dcoatにと、そんな事をしている場合じゃないだろう。
とは思うのですが、興味があることをやるのが一番、そう自分に言い聞かせてふらふらしております。

 

うーん、自分も人の役に立つようなスクリプトを作らなければ。

雑記84 – ローマ時代の建築と現代の建築から

以前建築の事について書いたので、ローマ時代の建築との比較から現代を見てゆきたいと思います。
塩野七生さんが書く所によると、ローマの建築の原点というべきものは、ローマの領土がその周辺地域に限られた時に既にできていたことを指摘しております。
当時執政官だったアッピウスは窪地で水の豊富なローマにわざわざ水道橋を引き、塩を取るために街道を整備した事がそれである。と書かれております。

 

先日偶然テレビを見ていると、偶然ローマの建築を特集しているものを見ることが出来ました。
そこでは、ローマが絶頂期に差し掛かったネロの時代を中心に描かれておりました。
皇帝ネロといえば、塩野さんの書き方だと、目立ちたがり屋の情緒不安定な青年、という印象を受けます。
彼は自ら楽曲を作り、市民を集めてコンサートを開いたりもしました。
芸術家を自認し、建築にも色々と口出ししていたようです。
そんな彼が暴君と呼ばれる理由は、彼の考案した建築計画にあり、ローマの中心地に巨大なドムス(個人宅)の建設にあったことを指摘されていたかと思います。
その予定地が突然の火事により消失し、住民を立ち退かせる必要が無くなりました。
市民の間からは皇帝が意図的に起こした火事ではないか、という噂が立ち、それまで人気者でチヤホヤされていたネロは
市民たちの反応に戸惑い、その火事を当時まだ圧倒的な少数派であり、異端であったキリスト教徒に押し付け、彼らを虐殺しました。
そして、その後キリスト教徒により暴君と綽名されるようになった。
歴史上もっと人を殺した人がいるだろうに、たった100人そこらで暴君と呼ばれるには少し可哀想だ。と塩野さんは書かれていたかと思います。

 

塩野さんはネロに対して、外交と経済面に関して十分に皇帝としての責務を果たした。と評価されていたかと思います。
しかし、どうやらネロは建築に対してもそれなりの政治手腕を見せたようで、テレビの特集では、
当時火事の絶えなかったローマを作り替えるために、車道を広くし、歩道に現代のアーケードのような柱廊を設置するよう義務付けたそうです。
そして、ローマ周辺から採取されるセメントが大いに使われるようになったのも、この頃のようです。

 

当時の都市部にはドムスという個人邸宅は余程の金持ちしか持つことが出来なかったそうで、大半の人はインスラと呼ばれる集合住宅で暮らしていました。
インスラの一回部分はテナントになっており、工房や商店が入っていたようです。
二階以上が住居となり、階を上がるごとに建築はお粗末なものになり、住んでいる人もそれに比例して所得が下がったそうです。
考えてみれば当然の事ですが、火事などの災害時に最も危険なのは上の階で、エレベーター等が無い時代、最も不便なのも上の階です。
現在では全く逆の事が言えるかと思いますが、先の震災でその当然さが浮き彫りになりました。
行政は建物の一階部分しか責任を持たないそうで、特に高層マンションの最上階に住んでいる方などは場所によっては大分大変だったかと思います。

 

当時のローマの生活を現代に例えるならば、キャンプ場を思い浮かべるといい。という人もいます。
トイレ風呂はなく、外食する習慣が多かったようなので、台所が無い住居もあったようです。ただ、台所はあっても現代のように優先はされません。
料理をするのはあくまでも奴隷の役目です。
汚物を窓から捨てることを禁止する法律もあったことから、公共のトイレに行くのが面倒で窓から投げ捨てていた人もいたのだろうと思います。

 

話がそれました、それたついでに当時のローマの生活を見てみたいと思います。
当時のローマは日本のように、性に対して緩やかで、シャーマニズムが生きる場所で良く見受けられる、生殖器に対する崇拝がありました。
商店の店頭には、青銅などで作られた男性器を模した物がまとまってぶらさがっていたようで、それを鳴らすと縁起が良い。とされていたようです。
そして、それは「ティンティンナーブラ」と呼ばれていたそうです。思わず下ネタか、と突っ込んでしまいそうな名前です。おかしな偶然もあるものです。
そして、食堂によっては、そこで働く奴隷の女性が気に入れば、別室で違うサービスも受けることができたそうです。
ものの価値が違うので、現在のお金の価値と比較することはとても難しいことですが、大体小麦粉一キロ分の値段、がその時の料金だったそうです。
100円から200円と言ったところでしょうか。そうなると犯罪率も経るのかなぁ、などと考えると中々深い問題を秘めています。

 

うーん、随分下品な方向になってしまいました、、建築の話は全く関係ない。
そういえば、前回紹介した「構造デザイン講義」では、911の時に破壊された貿易センタービルについても書かれていました。
その当時、マスコミも報道していましたが、あれだけのものがあれだけ容易く壊れるものか。と自分も考えておりました。
しかし、建築家の中には良くあれだけもったものだ。という人もいるそうです。
というのも、超高層ビルというのは、中央にスティール製のエレベーターシャフトが最も重要であり、
それはスティール製、ということもあり、300度の熱で簡単に変形してしまう。
要するに超高層ビルというのはバラックを積み上げただけのものだ。という人もあるそうです。
なるほど文明が大きくなると大変なものだ。と、そんな文明に生き、思います。

Maya Script Python スキニングウェイトの四捨五入 その2

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( oSel, v=True )
	oSkt = "findRelatedSkinCluster " + oShp + ";"
	oCls = maya.mel.eval( oSkt )
	oMxc = cmds.getAttr( oCls+".maxInfluences" )
	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 ) ) :
		w2 = 0.0
		oWei = cmds.skinPercent( oCls, oVtx[v], ib=0 ,query=True, value=True )
		oJnt = cmds.skinPercent( oCls, oVtx[v], query=True, transform=None )
		while 0.0 in oWei: oWei.remove(0.0)
		oDic = dict(zip(oJnt,oWei))
		i = len(oDic)
		for j,w in sorted(oDic.items(), key=lambda x:x[1]) :
			if i > oMxc : w = 0.0
			w = float( '%.2f' %w )
			if i != 1 :
				w2 += w
				if w2 > 1.0:
					w = w2 - w
			else :
				w = 1.0 - w2
			oDic[j] = float( '%.2f' %w )
			i -= 1
		cmds.skinPercent( oCls, oVtx[v], nrm = False , transformValue=( oDic.items() ) )
		cmds.progressBar( gMainProgressBar, edit=True, step=1 )
	cmds.setAttr( oCls + ".normalizeWeights", 1 )
	cmds.progressBar( gMainProgressBar, edit=True, endProgress=True )

性懲りもなくまだやっております。
pymelの恩恵が殆ど無いため、Pythonに戻しました。
Pymelだと最初の読み込みに少し時間がかかるようです。一度読みこめば速度は変わらないのですが、
恩恵を預っているスクリプトでもないし、ということでPythonに書きなおしました。

 

しかし、相変わらず美しくないソースだ。全然Pythonらしくない。
本を買って勉強するべきか、迷っております。
一応新たな試みとして辞書を使って見ました。他の言語で言う連想配列というやつです。
そして、最も大きな試みとして行った修正があります。
melバージョンのスクリプトを使っていても思ったのですが、細かい値がどうも納得が行かない。
今回自分でそれを参考に作ってみて分かりました。
ウェイトの値の大きさに関係なく、頂点の順番で処理しているから細かいところで誤差が出るのだと思います。(憶測)
なので今回はジョイントのリストとその値のリストをディクショナリにまとめ、値を参照して小さい順にソートして処理をしております。(多分)
まだそれ程デバッグしたわけではないので、確信はありません。済みません。

 

もっと良い方法あるのかなぁ?
とりあえず今度の目標は、できるだけ処理を関数化して、内包表記を使って処理を早くしてみる事かと思っております。
いやぁー、そんな事している場合でもないなぁ、、

追記と修正2011/12/10
すみません、、まともにチェックしていませんでした。
以前のままだとインフルエンスの数を超えてしまう場合があります。
修正版ではインフルエンスの数を超えたものは小さいもの順に削除されるようになりました。
あと、チェックスクリプトも更新しておきます。こちらはもっとまともに動いていない、、

Maya Script Pymel スキニングウェイトの四捨五入

from pymel.core import *
import maya.mel

def RoundWeight():

	oSel = selected()[0]
	gMainProgressBar = maya.mel.eval( '$tmp = $gMainProgressBar' );
	oVcount = polyEvaluate( oSel, v=True )

	oCls = maya.mel.eval( 'findRelatedSkinCluster ' + oSel + ' ;' )
	setAttr( oCls + ".normalizeWeights", 0 )
	oVtx = ls( oSel + ".vtx[*]", fl=True )
	progressBar( gMainProgressBar, edit=True,beginProgress=True, status='Now Rounding...', maxValue=oVcount )
	for v in range( len( oVtx ) ) :
		oW2 = []
		w2 = 1.0
		oWei = skinPercent( oCls, oVtx[v], ib=0 ,query=True, value=True )
		oJnt = skinPercent( oCls, oVtx[v], query=True, transform=None )
		while 0.0 in oWei: oWei.remove(0.0)
		for i,w in enumerate( oWei ) :
			w = float( '%.2f' %w )
			if i != (len(oWei) -1) :
				w2 -= w
				if w2 < 0:
					w = w + w2
			else :
				w = w2
			oW2.append( float( '%.2f' %w ) )
		oLst = zip( oJnt, oW2 )
		skinPercent( oCls, oVtx[v], nrm = False , pruneWeights=0.009, transformValue=( oLst ) )
		progressBar( gMainProgressBar, edit=True, step=1 )
	setAttr( oCls + ".normalizeWeights", 1 )
	progressBar( gMainProgressBar, edit=True, endProgress=True )

Pymelで書いて見ました。といっても、殆どその効用はありません。
ただ、それとは別に今回はきちんと動くようにしました。

 

元々melで書かれていたものを改めてみると、理解できなかった分岐が理解できるようになっていました。
その分岐があるから、一つの頂点のウェイトを合計して1になるのですね。勉強になりました。誠にありがとうございます。
進歩していないように思えても、少しは進歩しているようです。まだまだ先は程遠いいですが、、
もっとスマートな書き方があるかと思いますが、現状ではこのくらいしか出来ません。
使いやすいようにカスタマイズしてください。そしてできれば教えて下さい。

 

このスクリプトはオブジェクトを選択し、実行するとスムーススキニングの値を小数点以下二位までの桁で四捨五入してくれます。
float( ‘%.2f’ %w )の2を1に変更すれば多分小数点以下1位で四捨五入します。試しておりません。

 

いやー、しかし良かった。作ったものがきちんと動くと気持ちの良いものです。
ただ、殆ど人様が作ったものを参考にしているので、有難い限りです。

Pythonの内包表現

from pymel.core import *

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

Pythonの内包表現という物が以前から気にはなっていたのですが、改めて調べてみて使って見ました。
以前公開したノーマルマップの確認用のPymelですが、内包表現で書きなおしたものです。

 

一行で書けるものですが、読みにくいので改行しました。
Pythonは改行やインデントに対して、基本的には厳しいのですが、括弧内に関しては
そういった事は無視されるようで、この場合は問題なく動作します。
なんだか奇っ怪な言語です。面白いです。

 

そして、modoのスクリプトなどもつくってみたのですが、
作り比べてみるとツールの違いが良く分かります。
Mayaはそもそもがスクリプトを使うことが前提になっているので、とてもスクリプトが作りやすい構造になっています。
全てがノードベースになっているので、色々な方法でノードを辿ることが出来る上、当たり前の話ですが同じパラメータに関しては、
同じ様にアクセスできる。

 

それに対してmodoは同じ種類パラメータでもアクセスの方法が違ったりします。
うーん、ややこしい、、
確かに自己発光は他の物とは違うかと思いますが、ちょっとスクリプトが作りにくい、、
もうちょっと良いアクセスの方法があるのかも知れません。
うーん、勉強が足りない。

modoでライティング2 – 小物スクリプト – エッジの削除、投げ縄スタイルの切り替え

23
hdriをライティングと背景に使い、フォトショップでの調整なしでのレンダリングです。
jpegにすると少し色が濃くなるようです。ガンマが変わっているのでしょうか?前回の画像もちょっと濃い、というか暗めです。何故だろう?

 

そういえば、前回の勉強会で話題になった、エッジの削除についてスクリプトを作って見ました。
大した事をやっているわけではなく、ただ1つだけエッジが選択されている場合は「エッジの除去」になり、複数選択されている場合、もしくは違う選択モードの場合は「リムーブ」
コマンドが使われる。というだけです。
リムーブだとポイントも削除されてしまい、ポイントは残したいけどエッジは削除したい時に使ってください。
個人的にはリムーブはよく使うので、「Shift」+「z」に割り当てていますが、スクリプトをそれに割り当てています。
うーん、もうちょっと複雑な条件を考えたほうがいいのだろうか?とりあえずの回避策です。
edgeRemove

 

小物ついでにもう一つ。
自分は選択ツールを使う時は、いつもラッソで使っておりますが、矩形で選択したいこともある。
という時に切り替えを行うスクリプトです。実行すると、ラッソと矩形のトグルで選択が変わります。
selMode
これまた超小物スクリプトです。

 

そして、Luxologyのサイトを開いた時に表示される画像を見ながらちょっと真似して見ました。
24
うーん、難しい、、全く及ばない。やっぱりあのレンズフレアのようなものは合成なのだろうか。

modoでライティング

2122
勉強会で教わったことを元に色々と試しておりました。
どうも自分にはフィジカル・サンは使いこなせない、、結局4色グラデーションとhdriでレンダリングして見ました。
左が4色グラデーションで、右がhdriでの間接光ライティングです。

 

そして、どちらもモンテカルロでレンダリングしました。
間接レイを8192まで上げてみたのですが、40分弱でレンダリングできました。
場合によってはイラディアンスキャッシュよりも早いようです。

 

右の画像はもう少し明るくしたほうが良さそうです。
うーん、難しい。

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

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

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