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を使えないか検討中だけど、結構むずい。