GTS450 vs GTX750Ti

もうすぐGTX1050が出ようと言うのに今更ながら、おそらく底値になったところで、GTX750Tiを買ったのでざっくりと比較
比較対象は、以前うちにドナドナされて来た時から付いていて今は粗方中身が入れ替わっているが生き残っていたGTS450

数字的にざっくりと2倍程度の性能だが、BlenderのメッシュをSubsurfモデファイアで分割数を増やした時のfpsの落ち込みが低い
これはFermi→Kelperでも見られたことで、Kelper→Maxwellで変化があるかはデータが無かったが、Kelper→Maxwellでも速くなっているっぽい

fps_benchmark_V2.blendのlv6で200万スクエア。これのベースメッシュを1段階分割して800万ポリゴンにして11fps、もう一段分割して3200万ポリゴンにすると1.77fpsなので、1000万スクエアぐらいまでは作業的には堪えうる・・・かも
15fps辺りを閾値と考えれば500万スクエアまではいけるか・・・と言ったところ

		GTS450	GTX750Ti
Blender Benchmark
BMW27.blend		05:49:02	03:23:85	58.406%
fps_benchmark_V2.blend	lv6	3.27	28.81	8.810
	lv5	12.80	48.51	3.790
	lv4	46.79	60.10	1.284
	lv4	59.91	-	-
WinSAT
Direct3D Batch のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D Alpha Blend のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D ALU のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D Texture Load のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D Batch のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D Alpha Blend のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D ALU のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D Texture Load のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D Geometry のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D Geometry のパフォーマンス		42.00 F/s	42.00 F/s	-
Direct3D Constant Buffer のパフォーマンス		42.00 F/s	42.00 F/s	-
ビデオ メモリのスループット		15743.10 MB/s	3901.80 MB/s	2.153
Dshow ビデオ エンコード時間		1.34264 s	1.36166 s	1.014
メディア ファンデーション デコード時間		0.19273 s	0.10409 s	0.540

Blender : Add-on : Mouse Navigation Ext.

3DViewからユーザー設定オプション[Zoom To Mouse Pointer's position in 3D View]と[Rotate Around Active]を切り替えるアドオン

Add-on that switch UserPref Options [Zoom To Mouse Pointer's position in 3D View] and [Rotate Around Active] From 3D View.

http://www.pasteall.org/55032/python

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.

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日頃	童謡にもあるように秋の夜長の夜長月で長月
１０	神無月 kannnaduki	小雪	11月23日頃	新嘗の季節で醸成（かみなり）月、神嘗月、台風の季節の後で雷無月など
１１	霜月 shimotsuki	冬至	12月22日頃	霜が降りる季節で霜月
１２	師走 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
１０	October	第8の月 9th month
１１	November	第9の月 9th month
１２	December	第10の月 10th month

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

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

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

Sculptの続き

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

Blender久方

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


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

rigifyをGenerateして関連付け。

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

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

分割レベル3まで。


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

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


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

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


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

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


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

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

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

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

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

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
File	master.py		utils.py
Befoer	984 line	self.slave_timeout = 5 # 5 mins: need a parameter for that	162 line	def clientConnection(netsettings, report = None, scan = True, timeout = 5):
After		self.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.

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...

Blender Add-on : Real-time Lipsync Debug

Lipsyncスクリプトをvoxforge.orgの英語辞書を使ってデバッグ＆一部変更。

1. tri-phone + 長音が正しく処理されていなかった不具合を修正
2. Linuxで相対パスが正しく処理されなかった不具合を修正
3. ストリームバッファを4096→8192に拡張
4. 棄却値を尤度から尤度×レベルに変更（音量0.1でも尤度0.9と言う風に感覚的に解り難かったため）

I debugged the lipsync script and change some of the functions with English model from voxforge.org.

1. Repair the bug that it can't correct the combination of tri-phone with long-voice( : ).
2. Repair the bug that it can't correct the relative path in Linux.
3. Extend the stream buffer from 4096 byte to 8192 byte.
4. Change the thresholds from the plausibility to the plausibility multiplied with the volume( because it was hard to know such cases like that in a sencibility, the plausibility is 0.9 even though the volume is 0.1.) 

英語の辞書について
voxforge.orgの辞書＆モデルをダウンロードして、単語辞書にCMU音響モデルのwikiにある単語を追加してテストしていますが、品質がそれほどよく無く、エラーも多いので対応するトライフォンが無いと言うエラーは解消する程度には辞書を充実させる必要があるかもしれません。
尚、voxforge.orgのモデルに添付されている辞書だけでもやはり同様のエラーが出るので、そもそも基本的には音響モデルがメインで辞書は動作させるための最低限のサンプルなのですが、 整合性の点では最初から甘いのでしょう。
また、スペイン語やポルトガル語のような開音節主体の言語は、そのかなりを日本語辞書で賄える筈です。

About English dictionary
I tested with the model and dictionaries from voxforge.org, and added the words from CMU phonemes wiki to that word dictionary. But that quality is not good, and it output many error and warn messages. So it may be necessary to correct the dictionaries as well as to remove the message that the tri-phone does not exist.
Even if we use voxforge.org default dictionary, the same message are output, so its correction is not good from the first, and it should be for working in the least with the English acoustic model.
In the languages with open syllable mainly like Espanol or Portuguese, Japanese language model can cover many.

リップシンクのメインモジュール
古い話なので今一度。オープンソースの音声認識ソフトjuliusのデバイスストリーミング処理のごく一部を改造して、サーバーモード時の出力レコードに音素候補をその尤度値と共にリアルタイム出力するようにしています。
使用には127.0.0.1:10500へのアクセスを許可する必要があります。

The core module
This lipsync core module is the modified julius as open source voice recognize software, its modified part is minimum, and make to output the phonemes list with plausibilities to the record in server mode.
It is necessary to open 127.0.0.1:105000.


Lipsync tool( modified julius and Blender add-on ) http://sites.google.com/site/khuuyjblend/home/blender/script/lipsync
julius ( julius original and Japanese dictionaries ) http://julius.sourceforge.jp/
voxforge.org ( English model ) http://voxforge.org/
CMN phonemes ( wiki ) http://www.speech.cs.cmu.edu/cgi-bin/cmudict

Blender-Sculpt 2

やはり、リトポ不要、もしくはテクスチャベイク後に一部貼り直し＋UV修正なベースメッシュを作る方がはるかに効率的か・・・

Anyway, to make the base-mesh as unnecessary to re-topology, or as necessary only to retake some parts of the mesh and uv, it looks much better than to make new mesh to re-topology...

Blender Add-on : BlendPose Add-on

BlendPose Add-on updated for Blender 2.63 API
http://sites.google.com/site/khuuyjblend/home/blender/script/blendpose

Blender-Sculpt

あまり使っていなかったスカルプトに挑戦中。
Blenderのスカルプトモードにハイド機能が追加されたため、廉価GPUでも全身いけるかな？と思ったからなんだけど、Multiresolution Lv3で大まかな形にする（下絵なしで作りながら考えていた。この無計画さが駄目すぎる・・・） ⇒ Lv4で全体の流れを削る ⇒ Lv5で均してディテールを詰める（いまここ）と言う流れ。全身のプロポーションを作る段階から分割数を多くしていると重すぎるからだが、これだと殊の外、時間が掛りすぎている。
と言うのは、ポリゴンが細かい方がブラシの効きがよく、粗いとかなり強引に引っ張ったりすることになる。
普通はこういうの一体何時間ぐらいで作るもんなんだろうか？

I'm trying SCULPT now, I have rarely used it before.
This is why I thought it possible with even low-rank GPU because Blender sculpt mode got HIDE function. But in a real, I make rough shape in Multiresolution modifire's Lv3( I made it without the design, and that haphazard is bad... ), decide shape in Lv4, make the detail and the surface smooth in Lv5 (Now, on here), because it is too heavy to display many polygons for making full body style, so it is hard to subdivide to high level from the first. But that task makes me to spend much time.
The blush is more useful with more dens polygons, and need to drive forcibly with rough polygon.
In general, how time do they spent to make such full body sculpt model.

Blender Add-on : Lipsync Tool #2

⇒ 詳細 / Details 作成中

構成 : Blender python-script + 改造版julius
入力 : 既定の録音デバイス（手動でjuliusを起動する場合は環境変数PORTAUDIO_DEV_NUMで変更可能）
必須 : julius用の音響モデル、辞書、及び設定ファイル
（基本juliusウェブサイトで公開されているものが利用できるが、設定ファイルにinputがmic以外で設定されているとエラーになる）
動作確認済：Ubuntu11.10_amd64、Windows32bit/64bit(Visual C++ 2008 SP1再頒布パッケージ要）
（ソースコードを公開しているので、上記以外の環境についてはご自分でビルドして下さい）
モジュールの配置：任意。但し、パスに空白を含まないこと。（Windowsの場合はportaudio_x86.dllを同一フォルダに置いておくこと）
設定ファイルの配置：任意。但し、パスに空白を含まないこと。


SET : Blender python-script + modified julius
INPUT : Default recording device(microphone) (If starting julius with handle,it can be changed with the environment value as PORTAUDIO_DEV_NUM)
MUST : The acoustic model , the dictionaries and configuration file for julius
(The configures published on julius web site is available, but if it has the line as input without mic, it can't)
TESTED : Ubuntu11.10_amd64、Windows32bit/64bit(Need Visual C++2008 SP1 republish package)
PLACE OF EXECUTABLE MODULE : Any, but the path must not include SPACE (If on Windows,portaudio_x86.dll must be put at where is same as the julius executable module)
PLACE OF CONFIGURE : Any, but the path must not include SPACE.

Blender Add-on : Lipsync Tool

Blenderのためのリアルタイム・リップシンク

概要
オープンソースの音声認識ソフト(STT)juliusを利用したリップシンクツールで、改造したjuliusを用いる。Linux、Windowsでのビルド、動作は確認済。小改造なのでおそらくMacでもビルド可能な筈。

機能
リアルタイムでマイク入力によるリップシンク（シェイプキーアニメーション）を行う。通常のレコードアニメーションではシェイプキーは登録されないため、ビューポートアニメーションでシェイプキーアニメーションを登録する機能を備える。
コアモジュール（julius）については、追加した引数によってリアルタイムで音素候補をウェイト付きで出力する機能を追加している。その他の機能は従来のjuliusと変わらず、辞書の設定、調整やサポートツールの利用も変わらない。

問題点
音響モデルと辞書。日本語についてはjuliusディクテーションKITのものがそのまま利用可能。
日本語以外については、現在のところ商用利用可能な日本語辞書はVoxforge.orgのGPLv2辞書ぐらいしか見当たらないが、単語辞書、文法辞書はデモ用の最低限のものしか登録されておらず、辞書にない音素記号は抽出出来ないので追加する必要がある。
juliusのフォーラムで紹介されているgoogleの辞書（有償）と言うのも加工が必要。
サイズが大きすぎてgoogleサイトに置けないので、公開時にはリンク先のみ記す。


The real-time lipsync for Blender

Overview
The lipsync tool with julius as an opensource voice recognize software(STT),it uses the modified julius. I built and tested on Windows and Linux. Its modify is a little,so perhaps it can on Mac,too.

Function
It animate shapekeys with mic in a real time. The standard recording animation function can't entry shapekeys, so it have also the function for recording action.
The core module as julius was added the function to output phonemes symbols with those wrights in a real time. There is nothing as different from the original julius without that. So the way to set or adjust the dictionary,and to use support tools is as same as for the original.

The Problem
It needs the acoustic model and the dictionaries. In Japanese,the dictionary in julius dictation Kit(Japanese only) is available,but in Other languages,I found only the GPLv2 dictionaries on voxforge.org. But its words and grammar dictionary is just for demo,it has the least. julius can't output phoneme symbols out of dictionary. So it must be added words dictionary.
Anyway,those dictionary files are too large to put on the google-site, because those include acoustic models.
So when I'll publish this tool,I'll note only the links for the dictionaries.

Blender-Script : Changed Matrix process

Blender2.62でまたMatrixの手順が変わった（バグ修正の続き）ので、リグ関係のスクリプトがまたアウトになったんじゃないかと思うが、今、こういうものを作っていたりするので、暇になったらまたチェックする。

 The process of Matrix was changed at Blender 2.62 again (it's the task to fix bug since 2.59?), so I was wondering that my rigging script might be broken again.
But now I'm making this and having other tasks, so when I get time,I'll check about them.