Blender.jp

"Difference" Sequence plugin

Goofster氏作。これはFRONTの画像とBACKの画像を比べ、違う部分だけを残すというものです。氏による解説のページをみていただいた方が早いでしょう。特に実写との合成時に便利だと思われます。残念ながら現在はWindows用のみです。

bf-blender / Windows (2004/06/03)

Gabio氏によるbf-blender6/05分ビルドの配布です。

本日分の新しいビルドです。
現在はすべてが穏やかです。今週何があったかを見てみましょう。

概要
- Bugの修正
- envmapレンダリング時に％が反映されるように（訳注：恐らく原文のミス）
- 反転されたObjectがOpenGLプレビューで正しく表示されるように
- game engine(python API)
- Metaオブジェクト用の"Transform Properties"。フローティングパネルです
- 内部計算がより正確に
- game engineのepydoc- PythonAPIの更新：新しいメソッド
- OOPS Windowの新機能！ Objectのペアレント（これは始まりにすぎません！）
- Ipo、OOPS、Action、NLA、Sequenceウィンドウに'Transform'メニューが追加

Commit:
sirdude氏Log:
Tom氏の追加がWindowsビルドに適用されました。
(私は#blendersaueを#blendercompilersではなく、#blendercodersに変更しました。実際に#blendercompilersを使っている人はいますか？)

Log:
Panagiotis Ppadokos氏のパッチにより、下記が修正：
Linuxでのswab()の暗黙的宣言により、source/blender/src内で__USE_XOPENが定義される必要があったのを修正。

私はまたSolaris版の修正のため、このファイルに#include を追加しました。

ton氏
Log:
バグ修正#1332
EnvmapのレンダリングにRender Buttons(F10)のレンダリングサイズの％ボタンが反映されるように。
まだEnvmapの保存については実装されていません…。

Log:
レンダリング変換時に正しい法線の取得と反転を行う方法について再コーディング。古い方法は反転した行列をみつけることにより、オブジェクト毎に解決しようとしていました。ディスプレイスメントマッピングとレイトレーシングが実装されてからは、この方法では不正確になりすぎています。また、法線の反転は常に頂点の法線をも正しく反転する結果になるべきでしょう。

解決方法は現在renderHelp.cにある'puno'(頂点の法線)フラグ(set_normal_flags)を完全に再計算することです。面の法線はこの段階までは反転しません。

二つめの大きな改良には、四角形平面が平らでないときに、三角形に正しく分割する計算があります。現在三角形は、実際のまわりの形状の情報を持つ頂点の法線を元に作成されるようになり、より滑らかになる結果になりました。
これがないと、面にほとんど平行にライトを照らした時、Ray-shadowがおかしくなります。繰り返しますが、ディスプレイスメントマッピングもこれの所為で改良されています。

三つめの修正は法線の反転をディスプレイスメントのコードから除去することで、現在はより綺麗な結果が得られました。
Log:
新しくBlenderは現在、OpenGL Draw時に反転された（負のサイズの）Objectを正しく表示するようになりました。
（前述のcommitにより、負のサイズのObjectによるRaytraceの異常も解決されました…）

displaylistフラグとObject/baseフラグのさらなるクリーンアップ。#define ACTIVEはfilesel.cに移動しました(ここでしか使用されていません)。
#define GONNA_MOVEはOB_を前につけました。

Log:
ポリゴン化される前のmballのカウンタが、リンクされているmballデータが勘定に含まれている場合におかしくなり、モデリング時に異常を生じていました。

Log:
バグ修正#1340
アルファキー(レンダリング)がskyのアルファ成分を1に設定していました…これはNeoGeo時代の古い習慣で、私は何のためのものだったか全く手がかりを持っていません…。恐らく、骨董品(訳注：石投げないでくだちい)のAmiga iffフォーマットか何かの所為だと思います。現在は0になっています。

Log:
報告#1338
ディスプレイスメントとAutosmoothのルーチンの順番を入れ替え、Autosmoothが最後になりました。これはFaceのディスプレイスメントを妨げ(はずし)、他のケースでも同様に鋭いEdgeが目立っていたようです。

kester氏
Log:
クリッピング平面内にある法線ベクトルの０チェック(例えばPythonが妙な投影行列を設定していたときなど)。
錐台バウンド球の変形をワールド座標に修正。

Log:
LightをPythonモジュールに追加。
Vertexクラスに属性を追加。

jiri氏
Log:
"Transform Properties"をMetaオブジェクトに追加(EditMode中に[N]）。locX、locY、locZ、dx、dy、dz、stiffnessが設定できます。

ton氏
Log:
Normalise()関数の制限が0.000000001あたりでした。floatが10^-37まであるため、これはまだ大きすぎです。さらにこの値はまだ二乗されているため、平方根が問題なく行えてしまいます。

現在は10^-35に制限され、極端に小さいObjectを極端にカメラに近づけた場合にFaceが消えてなくなるのを修正しました。(OOPz氏に感謝！)

kester氏
Log:
epydocをgame Pythonのリファレンスに使用（bpythonのように）。

hos氏
Log:
あるBoneのIK ConstraintがそのBoneとConstaintのターゲットBoneを持つArmatureを指すとき、IKの表示が異常になるバグを修正。

これを追跡してくださったStephane Soppera氏に感謝。

stiv氏
Log:
新しくObjectの選択状態を操作するための、Object.select()とObject.isSelected()メソッドを追加。
Campbell Barton氏の投稿です。

kester氏
Log:
GamePythonリファレンスの更新。
Actuatorのドキュメントを追加。

Log:
Sound Actuatorで必要になればDatabrowse Windowを表示するように。

sirdude氏
Log:
Cam氏のパッチにより、OOPSのメニューでペアレントが行えるように。

broken氏
Log:
'Transform'メニューをIpo、OOP、Action、NLA、Sequenceウィンドウに追加。

小さな調整を少し。

Log:
ボタンのカーブの小さな、ほとんど無意味な調整。

Stiv氏
Log:
バグ修正#1345
Curve.isNurb()のSegfaultの修正。

Blender presentations in Spain

6月3日と4日、スペインのSantiago de CompostelaとGijon Universityにおいて、スペインでYafRayで有名なAlejandro Conty Estevez氏とTon氏に会える会合が開かれ、3日にはTon氏がBlenderとオープンソースについてのスピーチを行うそうです。

bf-blender v2.33a / intel compiler optimized (windows)

従来Elysiunで活躍されていたAntares氏が、Blender.org::Testing Buildsへと場を移されました。

皆さんこんにちは。
Ton氏から私にこの話題についてのスレッドを作る旨を告げられました。おそらくあなた方の何人かは私がした、もしくは行っている編集版を知っているでしょう。

私の編集版のBlenderは特別にインテルコンパイラを使用しており、コードの書き換えや再構成といった基本的な改良から、分岐予測、ループ展開、現在のインテルやAMDプロセッサのパイプライン技術を使用した並行命令実行、もしくは、可能であれば浮動小数点数演算と整数演算の並行実行を行っています。

しかし、主な利点はSSE(Streaming SIMD Extension)やSSE2のような、インテル(そしてAMD)プロセッサの特別な命令セットを使用した結果にあります。これらの命令セットによる8×128-bitレジスタへの一括設定はMMX技術の後継で、SIMD(Single Instruction Multiple Data)の実行をサポートします。

これはCPUが内部キャッシュにある同じ演算（例えば配列YのベクトルにXをループ内で加えるなど）を実行できることを意味します。(訳注：当方が端折りすぎてるかも)

Blenderは単精度浮動小数点単位を使用しており、プロセッサのサポートするSSE2の計算はデータ上の正確な演算を3ステップ（ロード、実行、ストア）で行えます。通常は少なくとも12ステップは必要になります。

私のBlenderバージョンはまた自動的にCPUを判別するようコンパイルされており、何のCPU上で走っているかをチェックし、パフォーマンスを向上するのに最適な命令セットを使用します。

これは私の版がP-P4やAMDプロセッサを含むいかなるx86CPUでも走ることを意味します。

MSVC++の主なコンパイラ設定は以下のとおり:
/Qaxw: CPU自動判別と可能ならSSE(2)を使用します
/O3: 最大スピード最適化とハイレベル最適化
/Ob2: どの関数でもコンパイラの判断でインライン展開化されます

これらの設定は以下のモジュールでは動作しません：
FTF_ftfont
KX_ketsji
SG_SceneGraph

私はまたIntelコンパイラを特にBlenderカーネル関数(モジュール：BKE_blenkernel)とプリマリーレンダリング関数(モジュール：BRE_render)のプロファイルのために使用しています。これはまたパフォーマンスの向上とバイナリサイズの縮小も少し行われます。

このすべてが通常レンダリング時間を20-60％縮小し、GUIの反応を少しだけ向上してくれます。

このコンパイラのひと月完全な機能を使用できるデモバージョンがwww.intel.comにあります。このコンパイラをどうやってincludeし呼び出すかについてのすべての重要なドキュメントがデモバージョンに入っており、30秒以内でできます。

Elysin内のスレッド：
http://www.elysiun.com/forum/viewtopic.php?t=17626

Windowsバイナリ：
http://www.silentthunder.de/files/blenderintel.zip

この中には他に私がblenderのいくつかの関数をアセンブラで書き直したものがあります。その一つが下記の関数です。
（訳注：MTC_Mat4MulMat4関数(4x4行列同士の内積)が続きますが、長いので省略します。参照したい方は原文をどうぞ）。

レンダリングプロセスにプロファイラをかけた後、この関数が非常に多く呼ばれていたため、私はメモリ整列化のためにSSE2命令セットで書き直しました。これがその結果です：
（訳注：前記同様SSE2を使用したアセンブラコードが記述されていますが省略します）。

両ルーチンを単精度浮動小数点の乱数を用いた結果が下記です。

標準のコード: 2.934秒で51000回実行
私のコード: 2.936秒で13000000回実行

標準版より250倍も早くなっています。^^

私はこの投稿が長文でないことを願っています。
おつきあいいただきありがとうございます。

bf-blender / windows ATI slow ui fix

alien-xmp氏(kester氏)による、ATiグラフィックカードによるUIの描画の問題を改良したテストビルドです。なお、コンパイル時に命令セットにSSEを使用するよう設定されているため、SSEを持たないCPUは利用できない可能性があるとのことです。
また、他のグラフィックカードの場合でも、若干早くなっているらしいです。氏自身も互換性の検証のため、ATiのカード以外の人も試してみてほしいとのことです。

今回の速度向上は、具体的には、glFinishをglFlushに変更したことにより、従来はglFinishがGPUのレンダリング終了を待っていたのを待たないようにしたことによるものだそうです。
当方の環境では、レンダリングが若干遅い以外は正常に動作しているようです。UIが早くなったかはあまり実感できませんでした。