ページ

2013年10月25日金曜日

Blender : Script : Bugs

メンテはしてないけど、2.69RCで発見したこと
import bpy
from bpy import *

context.object
とすると現在のObjectを正しくフォーカス出来ない

bpy.context.object
とすると正常にフォーカスできる



I found those in 2.69RC, though I have not maintain my codes yet.

With
import bpy
from bpy import *

If writing
context.object
It can't catch current object.

But
bpy.context.object
It can catch current object exactly.

2013年9月9日月曜日

MEMO : 月の由来 : Souces of month names

日本:Japan
旧称中期(グレゴリオ暦)由来
睦月
mutsuki
雨水2月19日頃年始で家族睦んで睦月、初めの月で元つ月が訛ったもの、春を前にして萌月など
如月
kisaragi
春分3月21日頃如月は当て字、中国の二月をそのまま当てたもので日本語の“きさらぎ”とは関係無し。衣替えの季節で衣更着、発芽の季節で草木張月など
弥生
yayoi
穀雨4月20日頃木草弥や(いよいよ)生ひ月で弥生
卯月
utsuki
小満5月21日頃卯の花の咲く月で卯月、田植えの季節で植月など
皐月
satsuki
夏至6月22日頃苗を植える季節で早苗月。新暦(グレゴリオ暦)での梅雨はこっち。古書では五月と書いてさつき
水無月
minaduki
大暑7月23日頃梅雨が明けて(水が無くなって)水無月、もしくは田に水を張る季節で水月(無は当て字)など
文月
fumitsuki
処暑8月24日頃七夕で文字を書くから文月と言われるが七夕は中国より奈良時代に伝わったものなので、稲穂が含(ふ)む月で文月との説も
葉月
haduki
秋分9月23日頃紅葉の季節で葉月、稲穂が張る季節で穂張り月など
長月
nagatsuki
霜降10月24日頃童謡にもあるように秋の夜長の夜長月で長月
10神無月
kannnaduki
小雪11月23日頃新嘗の季節で醸成(かみなり)月、神嘗月、台風の季節の後で雷無月など
11霜月
shimotsuki
冬至12月22日頃霜が降りる季節で霜月
12師走
siwasu
大寒1月20日頃師(僧)が仏事で走り回るから師走。年果てる、し果つ、など

英語:English
名前/Name由来/Source
January時の神ヤヌスの月
Month of Janus as God of Time
February浄罪の月
Month of Cleaning Sin
March戦神マルスの月
Month of Martius as War God
April愛と美と豊穣の女神ヴィーナスの月
Month of Vinus as Goddess of Love, buety and fertility
May豊穣を司る地母神マイアの月
Month of Maius as Land Goddess for fertility
June結婚の女神ジュノーの月
Month of Junius as Goddress of Marrage
Julyジュリアス・カエサルの月
Month of Gaius Julius Caesar
August初代ローマ皇帝アウグストゥスの月
Month of Augustus as the first Roman emperor
September第7の月
7th month
10October第8の月
9th month
11November第9の月
9th month
12December第10の月
10th month

2013年9月2日月曜日

モデリング:人物:全身:001


今更ながら、番号を振ってみる・・・1からだけど。
100万(四角)ポリゴンでも全身だとこんな感じで、4Kテクスチャで全身描く程度には粗いので、細かい部分の形は出し難い。
予めベースメッシュの密度に差をつけてればいいんだが、どうせグリグリ削れば位置なんて動いちゃうし、と関節以外メッシュを詰めなかったのはいいのか悪いのか・・・耳は中途半端に形を作っていてかなり強引に弄ってるんで微妙なところだったりする。
ある程度作り込んでしまえば、特に手足をいくつも削るのは手間なので、流用素体の出来あがりと言ったところではあるが、ブラシの反応が操作不能レベルにならなければもう1~2段階分割したいと言う点では、現環境下での練習用の域を出ないのも、また事実ではある。

ベースメッシュは、マルチレゾをapply、もしくはApply BaseしたローポリにテクスチャをBakeするだけで、リトポ無しでもそこそこはポージングに堪えるようにはしてある。

2013年8月25日日曜日

Sculptの続き

あまり進展無し。
腹から下を削っているところ。
下のベースメッシュをレベル4まで分割したが、指の間、腋の下、大胸筋の腕への接続部分、股間、おっぱいの下等等、関節内側のRが(逆向きに)尖る場所はどうしてもポリゴンが荒れるのと、それ故にどうしてもしっくりと来ない。
しかし、レベル5まで分割すると440万□ポリ。
どうせ、10万ポリ以下のモデルにノーマルを焼き付けるだけなのに、そこまで分割して何ピクセルのイメージを使う積りだ?って話で、それなら荒れている部分だけイメージをレタッチしてもいい訳で、どうしたもんかな。

2013年8月10日土曜日

Blender久方

スカルプトとGPU性能の兼ね合いをどうするか考えながら放置していたのを“超”久々に再開。


rigifyに合わせて作ったものをベースリグのボーンの変形で体型変更。

rigifyをGenerateして関連付け。

そして、multiresモデファイアを使ってスカルプトで削る。

ダイナミックトポロジーはまだ、multi-resolutionUVが維持出来ないのと、全体を無造作に削りまくると異常に頂点が増えるので、取りあえずは自動分割で頂点数を管理しつつ。

分割レベル3まで。


精度的にはもう2段階分割レベルを上げたいが、そうすると400万□になって、GPUがGTS450だとかなり重い。

レベル4で妥協するか、ここからダイナミックトポロジーで細かい部分を削っていくかと言うのが悩みどころ。


UVを1枚ものにしようと思っていたけど、それはあきらめた。

全体的に歪み具合がバラバラになるのと、腕や脚が明後日の方向向いて反って塗り難い。


現状、まだ分割が粗いので顔は殆ど削ってないけど、完成イメージを掴むために、簡単な服とヘアスタイル案のメッシュ、そしてリップと目許に若干色を追加。

下絵も無ければ意図した訳でも無いが、どこかで見たような感じの顔。


ボーンへの関連付けは胸と首から上腕にかけて補助ボーンを追加して、自動ウェイトを掛けただけ。

Armature > MultiRes だと肘を90度以上曲げると、内側が崩壊する。

MultiRes > Armature だとポリゴンの崩壊はなくなるが、変形がやや尖った感じになる。

まぁ、リトポせずに破綻させずに動かせるほどベースを詰めてないしポリゴン数も無いので、まぁ、モブ用でだったら、レンダリングの重さはともかくとして、物量を抑えると言う点では、リトポやウェイトの修正を殆ど行わずに、ApplyBaseすればそのままでもそこそこ使えそうと言うぐらい。



video
そして、ずっと放置していたこれも2.6対応しようかと。
2.52で作ったときは、ClothのSelf-Collisionの精度が悪かったので、かなり複雑な階層構造でスカートとベストの衝突を回避したが、単純にベストとスカートを結合して、Quality、Collision、Self-Collisionのパラメータを上げるだけでこれぐらいで動くので、メッシュ構造、各部分の強度を調整すれば、Clothだけで十分いけそう。
他の物理シムにRigidBodyを使えないか検討中だけど、結構むずい。


2013年4月19日金曜日

Blender Net Render

Blender Net Renderの現状の問題と対策
→いつものひどい英語判/Terrible English version as always
→コード修正箇所

BlenderのNetRender add-onはユーザー設定画面で見て判る通り、ベータ版となっているが、現時点では以下の問題があると思われる
(1)大きなファイル、もしくは大量の外部ファイルを含むデータのレンダリングではクライアントがエラーを起こしやすい
(2)フレーム当たりのレンダリングが長時間かかる場合はエラーになる
(3)Force upload all filesを指定してもリンクデータの参照に失敗する

(3)の対策は、将来対応されることを期待しつつ、全てのスレイブサーバーにクライアントと同じパスで各データを参照出来るように設定しておくことで対処するとして、(1)(2)は実はタイムアウトの判定の方法に問題がある。

(2)に関しては、実際には通信用モジュールがタイムアウトを起こしているのではなく、応答間隔が長かった場合、つまり前回の通信から今回の通信までの間隔が一定以上であればエラーを発生させている、もしくは該当スレイブをジョブの対象リストから除外すると言う作業を行っている。
つまり、通信が出来ないためにタイムアウトを起こしている訳ではなく、処理の遅いサーバーをメンバーから外すと言う処理を行っている。
但し、このタイムアウトにする閾値が固定で与えられているため、例えば、閾値が30分であれば、1フレームの処理に最速のサーバーで1時間掛かる場合には100%失敗となる。

現時点、この閾値は5分になっている。
CGWORLD誌でトランスフォーマーのレンダリング時間が(最長?)1フレーム70時間と紹介されていたようだが、勿論、お話にならない。

そして、この対策だが、マスターのソースコードのタイムアウト時間を与えている箇所を修正する。
実際のソースコード上でもコメントで、UIで変更出来るようにしなければならないと言う旨が書かれている。
但し、この対策法、問題が無い訳ではない。
ジョブをキャンセルした場合も、次のジョブを受け入れるまでこの時間待つようになる。
つまり、レンダリング、1フレーム当たり1時間のジョブを実行出来るようにすると、ジョブをキャンセルした場合に次のジョブを受け入れるまでに1時間掛かる。

生存通知の有無によるタイムアウトと、処理が遅いことによるタイムアウトを区別していないために起こる仕様上の問題だが、ここを変更して対応時間を伸ばすと、ジョブをキャンセルして新しいジョブを投入する場合には手動でスレイブを再起動する必要がある。

クライアントのタイムアウトも固定で5秒タイムアウトするようになっている。
現状パイソンはマルチコアに対応していないし、コード自体も並行処理で生存通知を行うようになっていないので、データサイズが大きかったり回線が遅くて転送時間が長くなると、タイムアウトする。
クライアントがタイムアウトすると、
(1)データの転送が正常に終了したか判らない
(2)マスターからレンダリング済データをダウンロード出来ない
の2点が問題となるが、LAN内やFTTH環境下ではほぼ起こらない上、(2)はウェブUIかクライアントのボタンからダウンロード出来るので、問題としてはさほど大きく無い。



The problem of Blender NetRender and the countermeasure against it
→Python Code

Blender NetRender is Beta version as you can know from user preference, then I think that it has these problem following here.
(1)The error often happen on client when sending the large sized file or the data having many linked files.
(2)It can't render the data that its render need many time for 1 frame rendering.
(3)It failure to refer linked files even if ordering the option "Force upload all files".

About (3), we expect to be resolved in future, and then we make slave servers to be able to refer data directories with same path as client's.
About (1)(2), it has the problem in the way to decide timeout.

In (2)'s problem, it is not that the communication module is not in timeout, but it occur when current response arrive after spending many time from last response, so it is not that there is not response. So if the time spans were long, the master would cut off those slaves as low performance machine.
However, this thresholds are fixed in current code. For example, if you rendered such data as to spend 1 hour also with the most performance machine and if the threshold were 30 minutes, that job should lose certainly.

In current code, it was set to 5 minutes.
Before there was the article about Transformer TV animation in CGWORLD( a magazine in Japan ), it said that its rendering needed 7 hours / frame (it is the longest time of them?), so such is nothing but joke in current Blender NetRender.

The way against that problem, you must change python code ( the comment to need to make it adjustable by UI is written in the code, but yet ).

But this countermeasure has also problem.
If you enlarge the length until timeout, also the wait time for next job is enlarged.
So if you set 1 hour for timeout, the NetRender could process the task that needed 1 hour, but if you cancelled that job, the slaves would not receive next job for 1 hour.

It is because of bug in the specification, the timeout against impossible to communicate and the timeout against low speed machine are not distinguished. But that is why we must restart slaves with handle when when we cancel job ( or wait for that time ).

In client, there is the problem that the timeout length is given as fixed parameter, and it is 5 seconds.
That is why it finish with error if it need many time for sending by its data size or the network through put, becaise current python don't support multi-core and this program can't send survival signal while sending.
If client goes to timeout,the problems are these.
(1)We can't know whether the sending have finished or not.
(2)Client can't download the rendered results from master automatically.
The problem of (1) rarely happen in LAN or FTTH, and (2) is not so serious because we can download the result from master with web UI or client's get button.



マスターの待機時間を1時間、クライアントの待機時間を2分に延長する
Extend master wait time to 1 hour, client's to 2 minutes

Directory./2.66/scripts/add-ons/netrender
Filemaster.pyutils.py
Befoer984 lineself.slave_timeout = 5 # 5 mins: need a parameter for that 162 linedef clientConnection(netsettings, report = None, scan = True, timeout = 5):
Afterself.slave_timeout = 60 # 5 mins: need a parameter for that def clientConnection(netsettings, report = None, scan = True, timeout = 120):
※1フレームに30分を要する場合、chunk=5だとマスターの待機時間は150分以上必要になる
If it need 30 minutes per frame and chunk is 5, then the master wait time need more than 150 minutes.
※クライアントの待機時間は一見初期値が5秒だが、これを変更するUIは存在しないので実質固定値
The wait time of client looks just initial value in shortsighted, but there is not UI for changing that, so it is fixed parameter substantially.


コードを見た感じ、複数ソースに跨っているためざっくりと見ただけだが、スレイブのタイムアウトはWebUIの当該項目が更新されるタイミング=スレイブの場合はJobIDが変更されるタイミングで行っているっぽい。このため一覧からステータスの変わらないスレイブが外れやすく、ジョブが実行中にも関わらずエラーになるっぽい。
と言うことはウェブ画面を出さなければ、マスターがスレイブを除外する処理が走らない?

Though I saw just rough , the reason of slave timeout seems that it is checked at when the part of slave status is changed in webUI. That is why the slaves that its status is not changed are cut off, and the job become error even though it is running.
So the task that master reject slaves will not run if I don't use web UI?


ウェブ画面無しでもタイムアウトするタイミングは同じでした。残念。
The term to timeout was same even if without web UI.

2013年3月30日土曜日

Blender Add-on @ 2.66

Face Bone Tool


フェイシャルアニメーション(VSQリップシンク含む)が動かない。
Facial Animation (Including VSQ Lipsync) can't work.

原因はAction-CostraintのActionプロパティに値をセット出来ないためだが、セット出来ない理由は現在不明
The reason is to be unable to set action property of Action-Constraint, but I don't know why it can't set the property.

Deform Bone Aid @Face


Matrixの仕様が変わる(バグFIXの)度に修正してきたが、おそらく現状合っている・・・筈。
I changed it in every times when  the specifications of Matrix( Bug fix of Matrix ) was changed, and it is correct now....PROBABLY.

Deform Bone Aid @Body


メンテしてないです、ハイ
Yeah, I have not take care of this...

Real Time Lipsync


扱いが面倒なのでどうするかは困り者。
It is trouble , because it is difficult.

動作の前提条件として以下の事前準備が必要。
These are needed to work.

(1)ファイアウォール :IPアドレス127.0.0.1からIPアドレス127.0.0.1ポート番号10500へのアクセス許可
(1)Fire Wall : Permit access from IP address 127.0.0.1 to IP address 127.0.0.1 port 10500.

(2)juliusの音響モデルと辞書の登録
(2)Set up acoustic model and dictionaries for julius.

Blend Pose


2.66にてテキストエディタから動かした場合と、Add-onで動かした場合で、参照するスコープが変わってAdd-onで動作しなかったので、スコープを明示的に記述することで対応。
元々、Boneの初期位置を編集している振りをすることで、ConstraintsのようにTranslationプロパティを変えずにBoneを動かしているが、所詮フェイクなのでバージョンアップで動作しなくなる可能性あり。本命はScript-Constraintの復活。
It couldn't work in 2.66, even though it could work on Text Editor, not on Add-on, because the scopes on Text Editor and on Add-on were different.
Anyway, it work with faking to change initial position, it works without changing Translation property like Constraints. But it is just fake, it may be to be unable to work in future version. The best is revival of Script-Constraint.

VSQ Importer

Copy Driver Variables


メンテしてないです、ハイ
Yeah, I have not take care of this...